Re: [webkit-dev] WebKit memory management?

2008-09-17 Thread zaheer ahmad
 This makes it impossible to correctly shut down WebKit at runtime
on this topic, i see that few singleton/global objects
(ResourceHandleManager, Cache, allPages(Page.cpp) ) and possibly more are
not getting destructed when webview is closed on the linux/gtk port. I dont
know if this is an intended behavior or a bug, but this could be an issue in
cases where you want to do a shut down only of webkit library. comments?

thanks,
Zaheer

On Wed, Sep 17, 2008 at 12:58 AM, Paul Pedriana [EMAIL PROTECTED] wrote:

  You are correct, though non-PODs are intended to go through the base-case
 operator new, whereby this wouldn't apply. The newObject template would have
 applicability only to PODs or even just built in types like int/char. If
 somehow it was deemed that this means was needed for non-PODs, the typical
 solution is to use a macro, as in:

 #define newObject(Type) new(fastMalloc(sizeof(Type)) Type

 This has some advantages beyond argument passing over the template
 solution. We've used this approach fairly successfully on a large scale at
 my company.

 Paul



  Hi,
 I just wonder how you can pass arguments to your new operator when they are
 mandatory (no default constructor), in the following case:

 class Foobar{
 public:
   Foobar(int a,char* b);
 };
 class Barfoo{
 public:
   Barfoo(char* a);
 }

 Foobar* myFoobar=newObjectFoobar( ?? );
 Barfoo* myBarfoo=newObjectBarfoo( ?? );

 Reading your patch, I don't think this testcase will work... will it?

 Fred



 Le Tuesday 16 September 2008 à 20:28, Paul Pedriana a écrit :


   I'm curious to see the patch (just to give an idea how
  big the changes would be). Do you have it somewhere?

 The patch is at: https://bugs.webkit.org/show_bug.cgi?id=20422.
 I don't think this is a terribly difficult thing to implement (though
 I don't mean to imply that it's trivial either). It might take a couple
 iterations to make sure all instances are handled, though. I searched
 the code and found a couple thousand instances of the keyword 'new',
 though most of those would fall under the case of the base class operator.

  Ah I see now. So you want to isolate the malloc from
  WebKit module. Furthermore, you want to be able to
  kill WebKit *only* when something weird happens,
  am I correct?

 I want to be able to shut down WebKit at any time, and possibly restart it.
 If WebKit is used as a library within an application instead of being the
 application itself, then you want to initialize it when needed, but when
 it's
 no longer needed then you want to shut it down. Think of computer games
 like Grand Theft Auto whereby you are a character walking around the
 world investigating something; and your character walks up to a computer
 in the game and uses it to connect to the real web (using an embedded
 WebKit)
 to search for live-generated info for a while. When the character shuts off
 the virtual computer, the game needs the resources of that computer to
 go away, as the game needs to recover the RAM for the next thing the user
 does. It significantly improves heap fragmentation of that WebKit instance
 ran in a single contiguous block of memory such that when it went away
 there is a nice big clean space left over.

 That being said, your original case of killing WebKit when something weird
 happens is also a practical use case. Such a thing might in fact be memory
 exhaustion due to fragmentation.

 Paul



  The primary benefit of being able to override operator new is to be able
 to redirect all allocations for a library to a user-specified heap. With
 global operator new, allocated WebKit memory is mixed in with the rest
 of the application memory and there is no practical way to tell them
 apart or sequester them. This makes it impossible to correctly shut down
 WebKit at runtime, since you don't know where its memory is. A side
 benefit related to this is that this allows for better memory metrics
 gathering.


  Ah I see now. So you want to isolate the malloc from WebKit module.
 Furthermore, you want to be able to kill WebKit *only* when something
 weird happens, am I correct?



  The proposal provides for a base class that overrides global operator
 new. So any allocated classes use the same syntax as usual. Most of the
 source code would fall under this.


  Yes, that is true.



  For the case of non-class-based memory allocations (e.g. raw char
 array), the proposal provides a newObject and newArray template
 function. So instead of 'new int' you would way 'newObjectint' and
 instead of 'new char[32]' you would say 'newArraychar(32)'. However,
 there is an alternative approach which is to provide a custom operator
 new type, like so:
 struct WTF{};
 void* operator new(size_t size, WTF);

 and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
 conventional solution to namespacing operator new, where the C++
 standard doesn't allow for operator new being in a C++ namespace.
 Perhaps this 

Re: [webkit-dev] WebKit memory management?

2008-09-16 Thread Ferenc, Rudolf

Paul Pedriana wrote:
 The problem with this syntax is that you can't do the 
corresponding thing with operator delete, as far as I know.


You are correct; delete would still need to be done differently 
(assuming you don't define a deleteWTF macro).


Paul, do you have some idea how to #define such a deleteWTF macro?

The fact that operator delete cannot be overridden is one of the 
limitations of the C++ language. The primary reason why is that the 
compiler needs to generate delete calls for objects that throw during 
construction, and there isn't an easy means to convey to the compiler 
which delete in particular you want it to generate.


Paul



On Sep 15, 2008, at 1:53 PM, Paul Pedriana wrote:


Regarding purpose:

The primary benefit of being able to override operator new is to be able
to redirect all allocations for a library to a user-specified heap. With
global operator new, allocated WebKit memory is mixed in with the rest
of the application memory and there is no practical way to tell them
apart or sequester them. This makes it impossible to correctly shut down
WebKit at runtime, since you don't know where its memory is. A side
benefit related to this is that this allows for better memory metrics
gathering.

A related problem is that parts of WebKit currently make the assumption
that operator new == tcmalloc; this includes using them interchangeably
in the code (see JSVariableObject for example). tcmalloc is a fine heap
for some platforms but in most cases is not the best option for embedded
or console platforms. Currently WebKit heap memory is allocated by at
least four means: operator new, malloc, fastMalloc, and mmap. We would
like to see all memory allocation going through a single controllable
API (such as the proposed operator new), though for Unix platforms I can
see the benefit of mmap for the JavaScript VM.

Regarding syntax:

The proposal provides for a base class that overrides global operator
new. So any allocated classes use the same syntax as usual. Most of the
source code would fall under this.

For the case of non-class-based memory allocations (e.g. raw char
array), the proposal provides a newObject and newArray template
function. So instead of 'new int' you would way 'newObjectint' and
instead of 'new char[32]' you would say 'newArraychar(32)'. However,
there is an alternative approach which is to provide a custom operator
new type, like so:
   struct WTF{};
   void* operator new(size_t size, WTF);

and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
conventional solution to namespacing operator new, where the C++
standard doesn't allow for operator new being in a C++ namespace.
Perhaps this syntax is preferable. This can be #defined to simply newWTF
if desired, then it is practically identical to existing global new 
syntax.
The problem with this syntax is that you can't do the corresponding 
thing with operator delete, as far as I know.



FWIW, I have been testing the proposed patch in my copy and so far it
has been fine, but that of course includes only my uses.
I hope to look at your patch soon. I think we absolutely need to fix 
the broken overriding of the global operator new / operator delete, 
but I want to make sure the syntax we end up with is as friendly as 
possible, since it will be pervasive throughout the code.


Regards,
Maciej



Paul



If I understand Mr. Pedriana correctly, you are incorrect in 
assuming that
we would get reduced syntax readability. You may use the regular 
new
syntax that C++ programmers are accustomed to when allocating 
objects and
arrays of objects that inherit from AllocBase. Pedriana proposes 
that we
eventually add AllocBase as the base class of all root classes in 
WebKit,

thus making AllocBase the only root class.

The only time when you would need to use newObject/newArray is for 
some
stray new/new[] calls when allocating something that does not 
inherit from

AllocBase, i.e. a simple datatype.

I'm personally happy if we won't have the reduced syntax readability 
:-)


Still, I'm curious to see the use cases where it makes more sense to 
do this
instead of global new/delete overrides at the application level. 
Feel free to

enlighten me here...

(BTW, no need to CC me. I'm on the list).




___
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
begin:vcard
fn:Ferenc Rudolf
n:Ferenc;Rudolf
org:University of Szeged;Department of Software Engineering
adr;quoted-printable:;;=C3=81rp=C3=A1d t=C3=A9r 2;Szeged;;6720;Hungary
email;internet:[EMAIL PROTECTED]
title:Assistant professor
tel;work:+3662544145
tel;fax:+3662546723
x-mozilla-html:FALSE
url:http://www.inf.u-szeged.hu/~ferenc/
version:2.1
end:vcard

___

Re: [webkit-dev] WebKit memory management?

2008-09-16 Thread Ariya Hidayat

 The primary benefit of being able to override operator new is to be able
 to redirect all allocations for a library to a user-specified heap. With
 global operator new, allocated WebKit memory is mixed in with the rest
 of the application memory and there is no practical way to tell them
 apart or sequester them. This makes it impossible to correctly shut down
 WebKit at runtime, since you don't know where its memory is. A side
 benefit related to this is that this allows for better memory metrics
 gathering.

Ah I see now. So you want to isolate the malloc from WebKit module. 
Furthermore, you want to be able to kill WebKit *only* when something weird 
happens, am I correct?

 The proposal provides for a base class that overrides global operator
 new. So any allocated classes use the same syntax as usual. Most of the
 source code would fall under this.

Yes, that is true.

 For the case of non-class-based memory allocations (e.g. raw char
 array), the proposal provides a newObject and newArray template
 function. So instead of 'new int' you would way 'newObjectint' and
 instead of 'new char[32]' you would say 'newArraychar(32)'. However,
 there is an alternative approach which is to provide a custom operator
 new type, like so:
 struct WTF{};
 void* operator new(size_t size, WTF);

 and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
 conventional solution to namespacing operator new, where the C++
 standard doesn't allow for operator new being in a C++ namespace.
 Perhaps this syntax is preferable. This can be #defined to simply newWTF
 if desired, then it is practically identical to existing global new syntax.

 FWIW, I have been testing the proposed patch in my copy and so far it
 has been fine, but that of course includes only my uses.

I'm curious to see the patch (just to give an idea how big the changes would 
be). Do you have it somewhere?



-- 
Ariya Hidayat ([EMAIL PROTECTED])
Software Engineer, Trolltech (a Nokia company)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit memory management?

2008-09-16 Thread Maciej Stachowiak

On Sep 16, 2008, at 4:56 AM, Ferenc, Rudolf wrote:

 Paul Pedriana wrote:
 The problem with this syntax is that you can't do the  
 corresponding thing with operator delete, as far as I know.
 You are correct; delete would still need to be done differently  
 (assuming you don't define a deleteWTF macro).

 Paul, do you have some idea how to #define such a deleteWTF macro?

This is better done with template functions than macros in my opinion.

  - Maciej



 The fact that operator delete cannot be overridden is one of the  
 limitations of the C++ language. The primary reason why is that the  
 compiler needs to generate delete calls for objects that throw  
 during construction, and there isn't an easy means to convey to the  
 compiler which delete in particular you want it to generate.
 Paul
 On Sep 15, 2008, at 1:53 PM, Paul Pedriana wrote:

 Regarding purpose:

 The primary benefit of being able to override operator new is to  
 be able
 to redirect all allocations for a library to a user-specified  
 heap. With
 global operator new, allocated WebKit memory is mixed in with the  
 rest
 of the application memory and there is no practical way to tell  
 them
 apart or sequester them. This makes it impossible to correctly  
 shut down
 WebKit at runtime, since you don't know where its memory is. A side
 benefit related to this is that this allows for better memory  
 metrics
 gathering.

 A related problem is that parts of WebKit currently make the  
 assumption
 that operator new == tcmalloc; this includes using them  
 interchangeably
 in the code (see JSVariableObject for example). tcmalloc is a  
 fine heap
 for some platforms but in most cases is not the best option for  
 embedded
 or console platforms. Currently WebKit heap memory is allocated  
 by at
 least four means: operator new, malloc, fastMalloc, and mmap. We  
 would
 like to see all memory allocation going through a single  
 controllable
 API (such as the proposed operator new), though for Unix  
 platforms I can
 see the benefit of mmap for the JavaScript VM.

 Regarding syntax:

 The proposal provides for a base class that overrides global  
 operator
 new. So any allocated classes use the same syntax as usual. Most  
 of the
 source code would fall under this.

 For the case of non-class-based memory allocations (e.g. raw char
 array), the proposal provides a newObject and newArray template
 function. So instead of 'new int' you would way 'newObjectint'  
 and
 instead of 'new char[32]' you would say 'newArraychar(32)'.  
 However,
 there is an alternative approach which is to provide a custom  
 operator
 new type, like so:
   struct WTF{};
   void* operator new(size_t size, WTF);

 and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
 conventional solution to namespacing operator new, where the C++
 standard doesn't allow for operator new being in a C++ namespace.
 Perhaps this syntax is preferable. This can be #defined to simply  
 newWTF
 if desired, then it is practically identical to existing global  
 new syntax.
 The problem with this syntax is that you can't do the  
 corresponding thing with operator delete, as far as I know.

 FWIW, I have been testing the proposed patch in my copy and so  
 far it
 has been fine, but that of course includes only my uses.
 I hope to look at your patch soon. I think we absolutely need to  
 fix the broken overriding of the global operator new / operator  
 delete, but I want to make sure the syntax we end up with is as  
 friendly as possible, since it will be pervasive throughout the  
 code.

 Regards,
 Maciej


 Paul



 If I understand Mr. Pedriana correctly, you are incorrect in  
 assuming that
 we would get reduced syntax readability. You may use the  
 regular new
 syntax that C++ programmers are accustomed to when allocating  
 objects and
 arrays of objects that inherit from AllocBase. Pedriana  
 proposes that we
 eventually add AllocBase as the base class of all root classes  
 in WebKit,
 thus making AllocBase the only root class.

 The only time when you would need to use newObject/newArray is  
 for some
 stray new/new[] calls when allocating something that does not  
 inherit from
 AllocBase, i.e. a simple datatype.

 I'm personally happy if we won't have the reduced syntax  
 readability :-)

 Still, I'm curious to see the use cases where it makes more  
 sense to do this
 instead of global new/delete overrides at the application level.  
 Feel free to
 enlighten me here...

 (BTW, no need to CC me. I'm on the list).



 ___
 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
 ferenc.vcf___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 

Re: [webkit-dev] WebKit memory management?

2008-09-16 Thread Ariya Hidayat

 As paul had mentioned, typically on an embedded platform you would want the
 webkit library to work in a bounded memory (10Mb) and signal an OOM
 condition if it crosses that and recover gracefully(either cleanup
 caches/history, stop loading current page, restart the app if nothing
 possible) without impacting the system. you dont want this to happen too
 often in production build, but how can you guarantee with current
 implementation?

Though I kind of agree that a custom allocator is the first step towards this, 
I guess graceful handling of memory problem would require much more bigger 
and massive changes in the code.

I have no experience doing such thing, but looking at the current state of 
WebKit code, I reckon the effort would not be trivial.



-- 
Ariya Hidayat ([EMAIL PROTECTED])
Software Engineer, Trolltech (a Nokia company)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit memory management?

2008-09-16 Thread Paul Pedriana
 I'm curious to see the patch (just to give an idea how 
 big the changes would be). Do you have it somewhere?

The patch is at: https://bugs.webkit.org/show_bug.cgi?id=20422.
I don't think this is a terribly difficult thing to implement (though
I don't mean to imply that it's trivial either). It might take a couple
iterations to make sure all instances are handled, though. I searched
the code and found a couple thousand instances of the keyword 'new',
though most of those would fall under the case of the base class operator.

 Ah I see now. So you want to isolate the malloc from 
 WebKit module. Furthermore, you want to be able to 
 kill WebKit *only* when something weird happens, 
 am I correct?

I want to be able to shut down WebKit at any time, and possibly restart it.
If WebKit is used as a library within an application instead of being the
application itself, then you want to initialize it when needed, but when 
it's
no longer needed then you want to shut it down. Think of computer games
like Grand Theft Auto whereby you are a character walking around the
world investigating something; and your character walks up to a computer
in the game and uses it to connect to the real web (using an embedded 
WebKit)
to search for live-generated info for a while. When the character shuts off
the virtual computer, the game needs the resources of that computer to
go away, as the game needs to recover the RAM for the next thing the user
does. It significantly improves heap fragmentation of that WebKit instance
ran in a single contiguous block of memory such that when it went away there
is a nice big clean space left over.

That being said, your original case of killing WebKit when something weird
happens is also a practical use case. Such a thing might in fact be memory
exhaustion due to fragmentation.

Paul




 The primary benefit of being able to override operator new is to be able
 to redirect all allocations for a library to a user-specified heap. With
 global operator new, allocated WebKit memory is mixed in with the rest
 of the application memory and there is no practical way to tell them
 apart or sequester them. This makes it impossible to correctly shut down
 WebKit at runtime, since you don't know where its memory is. A side
 benefit related to this is that this allows for better memory metrics
 gathering.
 

 Ah I see now. So you want to isolate the malloc from WebKit module. 
 Furthermore, you want to be able to kill WebKit *only* when something weird 
 happens, am I correct?

   
 The proposal provides for a base class that overrides global operator
 new. So any allocated classes use the same syntax as usual. Most of the
 source code would fall under this.
 

 Yes, that is true.

   
 For the case of non-class-based memory allocations (e.g. raw char
 array), the proposal provides a newObject and newArray template
 function. So instead of 'new int' you would way 'newObjectint' and
 instead of 'new char[32]' you would say 'newArraychar(32)'. However,
 there is an alternative approach which is to provide a custom operator
 new type, like so:
 struct WTF{};
 void* operator new(size_t size, WTF);

 and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
 conventional solution to namespacing operator new, where the C++
 standard doesn't allow for operator new being in a C++ namespace.
 Perhaps this syntax is preferable. This can be #defined to simply newWTF
 if desired, then it is practically identical to existing global new syntax.

 FWIW, I have been testing the proposed patch in my copy and so far it
 has been fine, but that of course includes only my uses.
 

 I'm curious to see the patch (just to give an idea how big the changes would 
 be). Do you have it somewhere?



   

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit memory management?

2008-09-16 Thread Frederic Marmond
Hi,
I just wonder how you can pass arguments to your new operator when they are 
mandatory (no default constructor), in the following case:

class Foobar{
public:
Foobar(int a,char* b);
};
class Barfoo{
public:
Barfoo(char* a);
}

Foobar* myFoobar=newObjectFoobar( ?? );
Barfoo* myBarfoo=newObjectBarfoo( ?? );

Reading your patch, I don't think this testcase will work... will it?

Fred



Le Tuesday 16 September 2008 à 20:28, Paul Pedriana a écrit :
  I'm curious to see the patch (just to give an idea how
  big the changes would be). Do you have it somewhere?

 The patch is at: https://bugs.webkit.org/show_bug.cgi?id=20422.
 I don't think this is a terribly difficult thing to implement (though
 I don't mean to imply that it's trivial either). It might take a couple
 iterations to make sure all instances are handled, though. I searched
 the code and found a couple thousand instances of the keyword 'new',
 though most of those would fall under the case of the base class operator.

  Ah I see now. So you want to isolate the malloc from
  WebKit module. Furthermore, you want to be able to
  kill WebKit *only* when something weird happens,
  am I correct?

 I want to be able to shut down WebKit at any time, and possibly restart it.
 If WebKit is used as a library within an application instead of being the
 application itself, then you want to initialize it when needed, but when
 it's
 no longer needed then you want to shut it down. Think of computer games
 like Grand Theft Auto whereby you are a character walking around the
 world investigating something; and your character walks up to a computer
 in the game and uses it to connect to the real web (using an embedded
 WebKit)
 to search for live-generated info for a while. When the character shuts off
 the virtual computer, the game needs the resources of that computer to
 go away, as the game needs to recover the RAM for the next thing the user
 does. It significantly improves heap fragmentation of that WebKit instance
 ran in a single contiguous block of memory such that when it went away
 there is a nice big clean space left over.

 That being said, your original case of killing WebKit when something weird
 happens is also a practical use case. Such a thing might in fact be memory
 exhaustion due to fragmentation.

 Paul

  The primary benefit of being able to override operator new is to be able
  to redirect all allocations for a library to a user-specified heap. With
  global operator new, allocated WebKit memory is mixed in with the rest
  of the application memory and there is no practical way to tell them
  apart or sequester them. This makes it impossible to correctly shut down
  WebKit at runtime, since you don't know where its memory is. A side
  benefit related to this is that this allows for better memory metrics
  gathering.
 
  Ah I see now. So you want to isolate the malloc from WebKit module.
  Furthermore, you want to be able to kill WebKit *only* when something
  weird happens, am I correct?
 
  The proposal provides for a base class that overrides global operator
  new. So any allocated classes use the same syntax as usual. Most of the
  source code would fall under this.
 
  Yes, that is true.
 
  For the case of non-class-based memory allocations (e.g. raw char
  array), the proposal provides a newObject and newArray template
  function. So instead of 'new int' you would way 'newObjectint' and
  instead of 'new char[32]' you would say 'newArraychar(32)'. However,
  there is an alternative approach which is to provide a custom operator
  new type, like so:
  struct WTF{};
  void* operator new(size_t size, WTF);
 
  and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
  conventional solution to namespacing operator new, where the C++
  standard doesn't allow for operator new being in a C++ namespace.
  Perhaps this syntax is preferable. This can be #defined to simply newWTF
  if desired, then it is practically identical to existing global new
  syntax.
 
  FWIW, I have been testing the proposed patch in my copy and so far it
  has been fine, but that of course includes only my uses.
 
  I'm curious to see the patch (just to give an idea how big the changes
  would be). Do you have it somewhere?

 ___
 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?

2008-09-16 Thread Paul Pedriana




You are correct, though non-PODs are intended to go through the
base-case operator new, whereby this wouldn't apply. The newObject
template would have applicability only to PODs or even just built in
types like int/char. If somehow it was deemed that this means was
needed for non-PODs, the typical solution is to use a macro, as in:

 #define newObject(Type) new(fastMalloc(sizeof(Type)) Type 

This has some advantages beyond argument passing over the template
solution. We've used this approach fairly successfully on a large scale
at my company.

Paul



  Hi,
I just wonder how you can pass arguments to your new operator when they are 
mandatory (no default constructor), in the following case:

class Foobar{
public:
	Foobar(int a,char* b);
};
class Barfoo{
public:
	Barfoo(char* a);
}

Foobar* myFoobar=newObjectFoobar( ?? );
Barfoo* myBarfoo=newObjectBarfoo( ?? );

Reading your patch, I don't think this testcase will work... will it?

Fred



Le Tuesday 16 September 2008  20:28, Paul Pedriana a crit:
  
  
 I'm curious to see the patch (just to give an idea how
 big the changes would be). Do you have it somewhere?

The patch is at: https://bugs.webkit.org/show_bug.cgi?id=20422.
I don't think this is a terribly difficult thing to implement (though
I don't mean to imply that it's trivial either). It might take a couple
iterations to make sure all instances are handled, though. I searched
the code and found a couple thousand instances of the keyword 'new',
though most of those would fall under the case of the base class operator.

 Ah I see now. So you want to isolate the malloc from
 WebKit module. Furthermore, you want to be able to
 "kill" WebKit *only* when something weird happens,
 am I correct?

I want to be able to shut down WebKit at any time, and possibly restart it.
If WebKit is used as a library within an application instead of being the
application itself, then you want to initialize it when needed, but when
it's
no longer needed then you want to shut it down. Think of computer games
like Grand Theft Auto whereby you are a character walking around the
world investigating something; and your character walks up to a computer
in the game and uses it to connect to the real web (using an embedded
WebKit)
to search for live-generated info for a while. When the character shuts off
the virtual computer, the game needs the resources of that computer to
go away, as the game needs to recover the RAM for the next thing the user
does. It significantly improves heap fragmentation of that WebKit instance
ran in a single contiguous block of memory such that when it went away
there is a nice big clean space left over.

That being said, your original case of killing WebKit when something weird
happens is also a practical use case. Such a thing might in fact be memory
exhaustion due to fragmentation.

Paul



  
The primary benefit of being able to override operator new is to be able
to redirect all allocations for a library to a user-specified heap. With
global operator new, allocated WebKit memory is mixed in with the rest
of the application memory and there is no practical way to tell them
apart or sequester them. This makes it impossible to correctly shut down
WebKit at runtime, since you don't know where its memory is. A side
benefit related to this is that this allows for better memory metrics
gathering.

  
  Ah I see now. So you want to isolate the malloc from WebKit module.
Furthermore, you want to be able to "kill" WebKit *only* when something
weird happens, am I correct?

  
  
The proposal provides for a base class that overrides global operator
new. So any allocated classes use the same syntax as usual. Most of the
source code would fall under this.

  
  Yes, that is true.

  
  
For the case of non-class-based memory allocations (e.g. raw char
array), the proposal provides a newObject and newArray template
function. So instead of 'new int' you would way 'newObjectint' and
instead of 'new char[32]' you would say 'newArraychar(32)'. However,
there is an alternative approach which is to provide a custom operator
new type, like so:
struct WTF{};
void* operator new(size_t size, WTF);

and so 'new char[32]' becomes 'new(WTF()) char[32]'. This is the
conventional solution to namespacing operator new, where the C++
standard doesn't allow for operator new being in a C++ namespace.
Perhaps this syntax is preferable. This can be #defined to simply newWTF
if desired, then it is practically identical to existing global new
syntax.

FWIW, I have been testing the proposed patch in my copy and so far it
has been fine, but that of course includes only my uses.

  
  I'm curious to see the patch (just to give an idea how big the changes
would be). Do you have it somewhere?
  

___
webkit-dev mailing list

Re: [webkit-dev] WebKit memory management?

2008-06-04 Thread Paul Pedriana




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. 

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 stdlib.h
  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 stdlib.h
  
  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 have any calls to
system malloc at all, because often on

these platforms there is little or no memory available, as the

application has taken it all to distribute to private heaps as per
their

budget.

  
  
The direct calls are few and far between. They can easily be evaluated
to determine which, if any, have a legitimate need to call the system
allocator and the remainder updated to use "fastMalloc" / "fastFree".
I'd gladly review a patch that moves in this direction.
  
  
  One simple and effective way to solve this
problem is to provide a

memory config header file which defines macros or templates which

replace new/delete, malloc/free. Instead of calling global new, WC_NEW

(e.g.) is called instead.

  
  
How does this differ from FastMalloc.h and "fastMalloc" / "fastFree"
that I described in my previous email, other than addressing the
perceived problem with "operator new" / "operator delete"?
  
  
  
  This is how commercial-quality software is
done

  
  
  
Kind regards,
  
  
Mark Rowe
  
  




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit memory management?

2008-06-04 Thread Alexey Proskuryakov

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?

2008-06-04 Thread Paul Pedriana




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?

2008-06-04 Thread Darin Adler
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 wtf/FastMalloc.cpp 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] WebKit memory management?

2008-06-04 Thread Darin Adler
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?

2008-06-04 Thread Justin Haygood
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?

2008-06-04 Thread Darin Adler
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?

2008-06-04 Thread Maciej Stachowiak


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 stdlib.h
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 stdlib.h

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 

Re: [webkit-dev] WebKit memory management?

2008-06-04 Thread Maciej Stachowiak

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?

2008-06-04 Thread Paul Pedriana
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_newT();
//T*   wk_new_arrayT(count);
//void wk_delete(T* p);
//void wk_delete_array(T* p);
//
// Example usage:
//char* pChar = wk_newchar();
//wk_delete(pChar);
//
//char* pCharArray = wk_new_arraychar(37);
//wk_delete_array(pCharArray);
//
//POD* pPOD = wk_newPOD();
//wk_delete(pPOD);
//
//POD* pPODArray = wk_new_arrayPOD(37);
//wk_delete_array(pPODArray);
//
//Object* pObject = wk_newObject();
//wk_delete(pObject);
//
//Object* pObjectArray = wk_new_arrayObject(37);
//wk_delete_array(pObjectArray);
//


template typename T
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 typename T
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 typename T
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 typename T
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 typename T
void VerifyIsAligned(T* p)
{
assert((size_t)uintptr_t)p ^ ((uintptr_t)p - 1))  1) + 1) = 
sizeof(T));
}


void DoSomething()
{
// char
char* pChar = wk_newchar();
wk_delete(pChar);

char* pCharArray = wk_new_arraychar(37);
wk_delete_array(pCharArray);

// double
double* pDouble = wk_newdouble();
VerifyIsAligned(pDouble);
wk_delete(pDouble);

double* pDoubleArray = wk_new_arraydouble(37);
VerifyIsAligned(pDoubleArray);
wk_delete_array(pDoubleArray);

// POD
POD* pPOD = wk_newPOD();
VerifyIsAligned(pPOD);
wk_delete(pPOD);

POD* pPODArray = wk_new_arrayPOD(37);
VerifyIsAligned(pPODArray);
wk_delete_array(pPODArray);

// Object
Object* pObject = wk_newObject();
VerifyIsAligned(pObject);
wk_delete(pObject);

Object* pObjectArray = wk_new_arrayObject(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 
 

Re: [webkit-dev] WebKit memory management?

2008-06-03 Thread Mark Rowe


On 03/06/2008, at 19:58, Paul Pedriana wrote:


As I have mentioned recently on this list, I am investigating the
possibility of porting WebKit to work within games on gaming  
platforms.

Recent help on this has been greatly appreciated and I am going to try
to stick with WebKit as opposed to Mozilla/Gecko.

A major consideration for the usage of libraries in general on gaming
and embedded platforms is that their memory usage be controllable. 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.


WebKit uses a derivative of Google's high-performance Thread Caching  
Malloc (http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html 
) for the majority of allocations.  We've tuned the allocator to add  
further performance gains over the system allocators on Mac and  
Windows, and have recently made further improvements to ensure unused  
memory is returned to the system.  Within JavaScriptCore and WebCore  
we overload operator new and operator delete in terms of our  
fastMalloc and fastFree functions to ensure all C++ object  
allocations go via this allocator (http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/FastMalloc.h 
).  The few direct calls to malloc and free within  
JavaScriptCore and WebCore are also made via our wrapper functions.   
This should make it straightforward to substitute your own custom  
allocator in place of WebKit's if it would better suit your target  
environment.


Kind regards,

Mark Rowe



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


Re: [webkit-dev] WebKit memory management?

2008-06-03 Thread Mark Rowe


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 have any calls to system malloc at all,  
because often on

these platforms there is little or no memory available, as the
application has taken it all to distribute to private heaps as per  
their

budget.


The direct calls are few and far between.  They can easily be  
evaluated to determine which, if any, have a legitimate need to call  
the system allocator and the remainder updated to use fastMalloc /  
fastFree.  I'd gladly review a patch that moves in this direction.



One simple and effective way to solve this problem is to provide a
memory config header file which defines macros or templates which
replace new/delete, malloc/free. Instead of calling global new, WC_NEW
(e.g.) is called instead.


How does this differ from FastMalloc.h and fastMalloc / fastFree  
that I described in my previous email, other than addressing the  
perceived problem with operator new / operator delete?




This is how commercial-quality software is done



Kind regards,

Mark Rowe



smime.p7s
Description: S/MIME cryptographic signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev