Re: [webkit-dev] HTML5 Application Cache
Michael Nordman [EMAIL PROTECTED], 2008-09-09 11:42 -0700: What is the status of the work-in-progress around the HTML5 AppCache that is in the repository? Is anybody actively working on that now? I'm interested in incorporating support for this feature into Chrome is why I'm asking. I'd been wondering the same thing myself, so I asked yesterday on #webkit on irc.freenode.net. The response from a couple of people there familiar with the code was that support for ApplicationCache (and I think in general for the offline-webapps part of the HTML5 spec) is on par with what's currently supported in Gecko. One limitation is that it doesn't support opportunistic caching -- but Gecko's implementation has the same limitation. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Application Cache
9 sep 2008 kl. 20.42 skrev Michael Nordman: What is the status of the work-in-progress around the HTML5 AppCache that is in the repository? Is anybody actively working on that now? I'm interested in incorporating support for this feature into Chrome is why I'm asking. Michael Hey Michael! As far as the specification goes, the two big parts that aren't implemented are opportunistic entries, and dynamic entries. Also, all I/O is currently synchronous which is of course something that we'd like to avoid. The relevant code is (as you probably already know) in WebCore/loader/appcache, but also elsewhere in the loader, surrounded by #if ENABLE(OFFLINE_WEB_APPLICATIONS). The code hasn't received a lot of testing (given that the spec is fairly new and in flux). Some regression tests are in LayoutTests/http/ tests/appcache. Any feedback/comments you have is of course much appreciated! Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit and Windows/Cygwin
At this point, I am at a total loss as I have yet to be able to build anything. Well, you got the error message. At the risk of pointing the obvious, I would say just trace the error message to find out where it fails. perl C:/cygwin/home/Administrator/WebKit/JavaScriptCore/pcre/dftables tmp\chartables.c --preprocessor=cl /E Error in tempfile() using \tmp\dftables-.in: Parent directory (\tmp\) is not a directory at Something is wrong with your Perl. What if you create the directory C:\tmp manually first? A side note: if you just want to give QtWebKit a try, why don't you use Qt 4.4? It has WebKit integration already (no need to build it if you use binary package). Refer to the following for details: http://doc.trolltech.com/4.4/qt4-4-intro.html http://doc.trolltech.com/4.4/qtwebkit.html Best regards, -- 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] How does the Javascript garbage collection work?
On Sep 11, 2008, at 12:13 AM, Josh Chia (谢任中) wrote:
I did some more research. It seems that KJS does mark-and-sweep GC,
and the marking is to mark objects that are not known to be
unreachable, so that those left unmarked can be removed at the end.
Please correct me if I'm wrong.
More specifically, it marks objects that are reachable from the root
set.
On Wed, Sep 10, 2008 at 9:23 PM, Josh
Chia (谢任中) [EMAIL PROTECTED] wrote:
Hi,
I'm trying to debug some memory leaks and now need to understand
what collector.{h,cpp} are doing. Could someone point me to some
documents to explain how the garbage collector works? I've also run
valgrind and it complained that CollectorBitmap::get() uses an
unreferenced value. I'm not sure whether this is really wrong, so
I'll have to first understand how the garbage collector works, the
alignment magic used with JSCell and whatever other GC magic I could
probably figure out on my own but only after staring at the code for
a long time.
We don't have detailed docs, but I can give you this overview:
The basic algorithm is mark and sweep. It's partially conservative -
it does a conservative scan of the stack for references but is exact
with respect to the heap (both its own and the C++ heap). Some of the
code may confuse valgrind but I do not believe there is actual
uninitialized access.
We arrange it so collector cells are always allocated at a multiple of
a power of two, this helps in part by making the conservative scan
cheaper.
It's really pretty straightforward in terms of algorithms, a fairly
amateur (but surprisingly effective) take on a garbage collector. In
the future we'd like to consider using a copying collector that
supports variable-sized allocations.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How does the Javascript garbage collection work?
Hi Josh,
When a C/C++ function allocates stack space (with decreasing the stack
pointer), it does not initialize the variables there. You need to
initialize them by assignment operators. Reading such variables by the GC
yields an error in valgrind.
Cheers,
Zoltan
Thanks for the reply. I have three more questions regarding this.
1. I'm getting many valgrind memcheck errors. I've added a few
suppressions
for them but I'm still getting tons of errors. Is this normal?
2. In my debugging, I found that Heap::markConservatively() and other
functions are reading from the stack. Heap::markConservatively(), in
particular, is scanning for pointers to mark. However some of the stack
addresses being read from are reported by valgrind as uninitialized, and I
think probably come from stack frame padding. Is this expected?
3. I am seeing some leaks for certain Node objects like FunctionDeclNode.
These use reference counting, not GC, but I think some GC'ed JS objects
hold on a reference to them. Is there a way to make the collector
completely GC everything, so that whatever remains, I can know for sure
are
true leaks?
Josh
On Thu, Sep 11, 2008 at 1:33 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Sep 11, 2008, at 12:13 AM, Josh Chia (л) wrote:
I did some more research. It seems that KJS does mark-and-sweep
GChttp://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html,
and the marking is to mark objects that are not known to be unreachable,
so
that those left unmarked can be removed at the end. Please correct me
if
I'm wrong.
More specifically, it marks objects that are reachable from the root
set.
On Wed, Sep 10, 2008 at 9:23 PM, Josh Chia (л)
[EMAIL PROTECTED]wrote:
Hi,
I'm trying to debug some memory leaks and now need to understand what
collector.{h,cpp} are doing. Could someone point me to some documents
to
explain how the garbage collector works? I've also run valgrind and it
complained that CollectorBitmap::get() uses an unreferenced value. I'm
not
sure whether this is really wrong, so I'll have to first understand how
the
garbage collector works, the alignment magic used with JSCell and
whatever
other GC magic I could probably figure out on my own but only after
staring
at the code for a long time.
We don't have detailed docs, but I can give you this overview:
The basic algorithm is mark and sweep. It's partially conservative - it
does a conservative scan of the stack for references but is exact with
respect to the heap (both its own and the C++ heap). Some of the code
may
confuse valgrind but I do not believe there is actual uninitialized
access.
We arrange it so collector cells are always allocated at a multiple of a
power of two, this helps in part by making the conservative scan
cheaper.
It's really pretty straightforward in terms of algorithms, a fairly
amateur
(but surprisingly effective) take on a garbage collector. In the future
we'd
like to consider using a copying collector that supports variable-sized
allocations.
Regards,
Maciej
___
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] How does the Javascript garbage collection work?
On Sep 11, 2008, at 1:53 AM, Josh Chia (谢任中) wrote:
Thanks for the reply. I have three more questions regarding this.
1. I'm getting many valgrind memcheck errors. I've added a few
suppressions for them but I'm still getting tons of errors. Is this
normal?
I think valgrind is overzealous here - it can't tell when we are
setting only one of a group of bits, and perhaps doesn't detect that
our memory is initially zero-fill.
2. In my debugging, I found that Heap::markConservatively() and
other functions are reading from the stack.
Heap::markConservatively(), in particular, is scanning for pointers
to mark. However some of the stack addresses being read from are
reported by valgrind as uninitialized, and I think probably come
from stack frame padding. Is this expected?
It is expected and not harmful. A false positive on the conservative
scan is not especially harmful.
3. I am seeing some leaks for certain Node objects like
FunctionDeclNode. These use reference counting, not GC, but I think
some GC'ed JS objects hold on a reference to them. Is there a way
to make the collector completely GC everything, so that whatever
remains, I can know for sure are true leaks?
Function objects hold on to things like FuncDeclNode. You can call
collect() manually to force a GC. We have a dialog in the Safari Debug
menu that lets you do that.
- Maciej
Josh
On Thu, Sep 11, 2008 at 1:33 AM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
On Sep 11, 2008, at 12:13 AM, Josh Chia (谢任中) wrote:
I did some more research. It seems that KJS does mark-and-sweep
GC, and the marking is to mark objects that are not known to be
unreachable, so that those left unmarked can be removed at the
end. Please correct me if I'm wrong.
More specifically, it marks objects that are reachable from the root
set.
On Wed, Sep 10, 2008 at 9:23 PM,
Josh Chia (谢任中) [EMAIL PROTECTED] wrote:
Hi,
I'm trying to debug some memory leaks and now need to understand
what collector.{h,cpp} are doing. Could someone point me to some
documents to explain how the garbage collector works? I've also
run valgrind and it complained that CollectorBitmap::get() uses an
unreferenced value. I'm not sure whether this is really wrong, so
I'll have to first understand how the garbage collector works, the
alignment magic used with JSCell and whatever other GC magic I
could probably figure out on my own but only after staring at the
code for a long time.
We don't have detailed docs, but I can give you this overview:
The basic algorithm is mark and sweep. It's partially conservative -
it does a conservative scan of the stack for references but is exact
with respect to the heap (both its own and the C++ heap). Some of
the code may confuse valgrind but I do not believe there is actual
uninitialized access.
We arrange it so collector cells are always allocated at a multiple
of a power of two, this helps in part by making the conservative
scan cheaper.
It's really pretty straightforward in terms of algorithms, a fairly
amateur (but surprisingly effective) take on a garbage collector. In
the future we'd like to consider using a copying collector that
supports variable-sized allocations.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How does the Javascript garbage collection work?
Is it possible for a false positive on the stack to prevent an object from
being collected even after calling collect() multiple times?
On Thu, Sep 11, 2008 at 9:45 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Sep 11, 2008, at 1:53 AM, Josh Chia (谢任中) wrote:
Thanks for the reply. I have three more questions regarding this.
1. I'm getting many valgrind memcheck errors. I've added a few
suppressions for them but I'm still getting tons of errors. Is this normal?
I think valgrind is overzealous here - it can't tell when we are setting
only one of a group of bits, and perhaps doesn't detect that our memory is
initially zero-fill.
2. In my debugging, I found that Heap::markConservatively() and other
functions are reading from the stack. Heap::markConservatively(), in
particular, is scanning for pointers to mark. However some of the stack
addresses being read from are reported by valgrind as uninitialized, and I
think probably come from stack frame padding. Is this expected?
It is expected and not harmful. A false positive on the conservative scan
is not especially harmful.
3. I am seeing some leaks for certain Node objects like FunctionDeclNode.
These use reference counting, not GC, but I think some GC'ed JS objects
hold on a reference to them. Is there a way to make the collector
completely GC everything, so that whatever remains, I can know for sure are
true leaks?
Function objects hold on to things like FuncDeclNode. You can call
collect() manually to force a GC. We have a dialog in the Safari Debug menu
that lets you do that.
- Maciej
Josh
On Thu, Sep 11, 2008 at 1:33 AM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Sep 11, 2008, at 12:13 AM, Josh Chia (谢任中) wrote:
I did some more research. It seems that KJS does mark-and-sweep
GChttp://www.hpl.hp.com/personal/Hans_Boehm/gc/complexity.html,
and the marking is to mark objects that are not known to be unreachable, so
that those left unmarked can be removed at the end. Please correct me if
I'm wrong.
More specifically, it marks objects that are reachable from the root set.
On Wed, Sep 10, 2008 at 9:23 PM, Josh Chia (谢任中) [EMAIL PROTECTED]wrote:
Hi,
I'm trying to debug some memory leaks and now need to understand what
collector.{h,cpp} are doing. Could someone point me to some documents to
explain how the garbage collector works? I've also run valgrind and it
complained that CollectorBitmap::get() uses an unreferenced value. I'm not
sure whether this is really wrong, so I'll have to first understand how the
garbage collector works, the alignment magic used with JSCell and whatever
other GC magic I could probably figure out on my own but only after staring
at the code for a long time.
We don't have detailed docs, but I can give you this overview:
The basic algorithm is mark and sweep. It's partially conservative - it
does a conservative scan of the stack for references but is exact with
respect to the heap (both its own and the C++ heap). Some of the code may
confuse valgrind but I do not believe there is actual uninitialized access.
We arrange it so collector cells are always allocated at a multiple of a
power of two, this helps in part by making the conservative scan cheaper.
It's really pretty straightforward in terms of algorithms, a fairly
amateur (but surprisingly effective) take on a garbage collector. In the
future we'd like to consider using a copying collector that supports
variable-sized allocations.
Regards,
Maciej
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How does the Javascript garbage collection work?
On Sep 11, 2008, at 10:57 AM, Josh Chia (谢任中) wrote: Is it possible for a false positive on the stack to prevent an object from being collected even after calling collect() multiple times? Sure. That's always theoretically possible with conservative garbage collection. But in practice this is unlikely and it is almost certainly not a practical problem. One of the things we do in WebKit is to make sure that garbage collection occurs when there is very little on the stack, by collecting at the top level of the event loop at key times (for example, when a window is closed). In my experience so far, when diagnosing a problem where an object was not collected, it has always been due to another cause. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit and Windows/Cygwin
I can assure you I've spent quite a bit of time attempting to debug and build. Again I'm following the instructions on http://trac.webkit.org/wiki/BuildingQtOnWindows as instructed by other responders to my post. There is a specific error that occurs prior to the build aborting. The problem involves rcc.exe. For example, I get an error like: c:\Projects\qt-win-opensource-src-4.4.1=bin\rcc.exe: File does not exist '..\..\..\WebCore\page\inspector\WebKit.qrc' Note that the file does indeed exist in the correct path. I have search on the internet for this type of error and have found posts on a couple forums where people (like me) attempting to build under Windows have seen this problem. Unfortunately, those posts are never answered. Again, the reason I am trying to build the source is as part of some research I am doing to see if WebKit is something we can use in the development of a thin client for a new product we are developing. I should also add that the build generates other errors later on in the file ..\..\..\JavaScriptCore\wft\Assertions.h. It complains of unexpected characters in certain macros formal parameter list. I apologize if I appear to be beating a dead horse, but I was hoping if I could at least build this stuff, I could begin digging into learning how it works. Frank -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ariya Hidayat Sent: Thursday, September 11, 2008 3:22 AM To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] WebKit and Windows/Cygwin At this point, I am at a total loss as I have yet to be able to build anything. Well, you got the error message. At the risk of pointing the obvious, I would say just trace the error message to find out where it fails. perl C:/cygwin/home/Administrator/WebKit/JavaScriptCore/pcre/dftables tmp\chartables.c --preprocessor=cl /E Error in tempfile() using \tmp\dftables-.in: Parent directory (\tmp\) is not a directory at Something is wrong with your Perl. What if you create the directory C:\tmp manually first? A side note: if you just want to give QtWebKit a try, why don't you use Qt 4.4? It has WebKit integration already (no need to build it if you use binary package). Refer to the following for details: http://doc.trolltech.com/4.4/qt4-4-intro.html http://doc.trolltech.com/4.4/qtwebkit.html Best regards, -- 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
