My questions would be:

What are the benefits of webkit2?
Does it have a higher memory footprint?
Are bugs still fixed for webkit1?
More generally asked: Is the step avoidable or only deferrable

@Fab
Are you willing to do it in the next couple of month?
Is money (an amount a bounty can realistically generate) a motivation for you?
Are there other morphos stuff you would prefer to do, that need funding?

Quote:

WebKit2's main advantage is that it has one process by browser object, but as jaca said, it's not as much interesting for us as it could be on platforms with virtual spaces and memory protection.

It probably has a higher memory footprint, since it creates a JS VM instance (and possibly also a WebCore instance) per browser (which IIRC is at least 4MB at initialization), plus all the process intercommunication overhead, of course.

Bugs are still fixed for webkit1, and in fact, it doesn't matter. Actually, WTF, JavascriptCore and WebCore are common to WebKit1 and WebKit2 (same source code, only initialization differs). For the record, WebKit1/WebKit2 are *just* the highest level layers in the browser, the ones responsible for the user interface and the object initialization. In WebKit2, everything is done in a multiprocess manner (JavascriptCore and WebCore are instanciated for each browser "view"), Network, download manager, events, rendering modules are designed around a central IPC controller, and so on...

Do I have the time to do it? No, and a bounty won't change that, and as said above, it's not that interesting, anyway. ATM, i'm working on sync'ing WebKit to a current version, which is more important IMO.

[ Edited by Fab 11.05.2015 - 07:21 ]

> What are the benefits of webkit2? Does it have a higher memory footprint?
> Are bugs still fixed for webkit1?

Fab already answered, but let me mention that these questions are also answered therein (plus other questions you might deem interesting regarding WebKit1 vs. WebKit2 vs. Blink):

http://events.linuxfoundation.org/sites/events/files/slides/slides_3.pdf
(it even mentions Sputnik and OWB)

Quote:
Wow, they managed to fix all the memory leaks & improve memory handling in the 2.x version? Wouldn't have believed that by using any of the "non-affected" browsers. </sarcasm>

Of course I was talking about WebKit "in general", new or old.

And as others already pointed out:
-Lots of WebKit1 issues still exist on WebKit2 (especially for us)
-Lots of code is still shared between the versions

But yes, there might be some memory-related fixes that haven't yet made it to WebKit1 (or are hard to backport due to architectural changes)

>>>> JavascriptCore allocate (lots of) memory blocks in virtual memory and these blocks
>>>> can only be released when all runtime references created inside these blocks
>>>> (javascript variables, objects, whatever) are released [...]. By design, in WebKit1,
>>>> the VM is shared by all instances, and it relies on that. In WebKit2, that's different,
>>>> each browser is isolated in a thread, with its own js VM instance, so it wouldn't
>>>> be a problem there. At task destruction, all the memory could easily be released.

>>> if it was easy to fix, some of the "big players" (Apple, Google, KDE, Opera...)
>>> would have already done that.

>> These "big players" don't use WebKit1 anymore anyway but WebKit2 or Blink*,
>> so their browsers are not affected.

> Wow, they managed to fix all the memory leaks & improve memory handling in the 2.x version?

I don't know about *all* the leaks, but they managed to circumvent the type of memory leak this thread is about and thus improved memory handling in WebKit2 compared to WebKit1 by going WebKit2's multi-process architecture route, so that closing a browser tab means all associated runtime references are actually released.

> Wouldn't have believed that by using any of the "non-affected" browsers.

It is you who claims that the "big players" not fixing this issue in WebKit1 means it is hard to fix. It may indeed be hard (or even impossible) to fix, but how can you conclude this from the "big players" not fixing it when they "simply" worked around the issue by going multi-process and gaining even more advantages this way in today's multi-core world as a sideline? Point is, they don't even need to fix this WebKit1 issue.

> Of course I was talking about WebKit "in general", new or old.

There is no need to fix the issue in WebKit2 because its multi-process architecture prevents it from having impact. And there is no need for the "big players" to fix the issue in WebKit1 because they use WebKit2 (see above) or Blink (with browser-level implementation of multi-process architecture).

> Lots of WebKit1 issues still exist on WebKit2

Not the one this thread was started about.

> especially for us

The "big players" you talked about (and to which I replied) don't care for us.

> Lots of code is still shared between the versions

The "fix" of the issue at hand lies in the part of the code that is not shared between the versions.

> But yes, there might be some memory-related fixes that haven't yet made it
> to WebKit1 (or are hard to backport due to architectural changes)

You almost got it. Go read Fab's postings and you'll know what these "fixes" to the issue at hand are.

Quote:

With http://aminet.net/search?query=vmm would that give us some benefit? The source code is there. Sadly I could not get VMM to run on MOS so far because it always tells me for all applications that they are not running although I started them. I do not know why it says so. But maybe someone else can get it to run. Yes, this VMM program is a hack but maybe a good one for now because it will take some more years until we get real virtual memory in MOS.

slow speed and the memory consumption is the biggest problem for me in OWB. Like when I want to watch a short movie on Youtube which is less than a minute then the progress bar says it needs to download maybe 2MB. The download window is only downloading an access site. But I can stay and watch for minutes that the CPU load is full, the fan is blowing after some seconds, the video is never started to play but more than 300MB of memory is eaten up or even more until the requester pops up: Retry - Quit - Crash.
When I do not wait for it but I press F12 before this requester then I get back about 1MB (values before and after in screenbar) but not the other 300 MB that the Youtube page needed. And the next problem is that when I close some tabs, then quit and restart OWB but with less open tabs than before, the memory was freed in the meantime but then OWB crashes again because it gets into the same trouble again. Why? Because RAM does not seem to be defragmented after freeing.

Quote:

It is said that VM was done for MorphOS ages ago already, but MorphOS team decided against adding it to MorphOS. AFAU mainly because it added no real beenfit as it has also the 1.5 GB limitation snd was rather slow.

But as there are machines that cannot upgraded to physical 1.5GB (mac mini, Efika,..) and SSDs changed the behavior (access speed) of hdds I would suggest a reconsideration about adding the option for VM eventually. Actually I experience quite a difference with my mini with 1 GB and my Powerbook with 1.5 GB. The latter virtually never runs out of mem, while with the mini this is an issue (let's not even start to talk about Efika...)

@Fab
Thank you, for taking the time to answer my questions

@Andreas_Wolf
Thanks for the link, interesting addition

Quote:

Yeah, it definitely would have all the same limitations, that already make it completely pointless on AmigaOS4.

With virtual memory (which doesn't have anything to do with swapping) it would be more interesting, but that would be a bigger change that would break lots of backwards compatibility, and not just with "old 68k software".

> WebKit2 [...] is not as much interesting for us as it could be on platforms with
> virtual spaces and memory protection. [...] Do I have the time to do it? No, and
> a bounty won't change that, and as said above, it's not that interesting, anyway.

You're doing it anyway?

http://translate.google.com/translate?sl=de&tl=en&u=http://www.a1k.org/forum/showpost.php?p=836842

I don't believe this for a second. I worked at multiple companies that manufactures setup boxes for DVB/IPTV; and basically everyone uses WebKit (regardless of the browser used, most commonly Opera, Netfront or Ekioh) essentially no setup box has more than 512MB RAM (where of about half is reserved for system use- especially MPEG acceleration), there is no swap at all.

Several runs their UI in a web browser, they have a second browser running HbbTV and often the same is used for arbitrary user surfing, there is no known problem with leaks that I ever heard of (atleast not to the extent it causes issues).
The same applies to essentially all "smart tv" etc.

Quote:

Nope. Plenty of smart TVs have memory issues and do have broken memory management related to JavaScript. I know at least one widely used js piece of code that'd cause TVs (Samsung, Philips) to run out of memory.

> setup box

;-)

Quote:

Well, the leaks are still there nonetheless. But in set top boxes case, the processes using WebKit are most likely disposed as soon as possible to regain memory, and also, the UI is hopefully not as resource hungry as something like google services or facebook, for instance. :) Keep in mind the js leaks are closely related to the way the page is coded. Some pages using Javascript might not cause WebKit to leak.

Quote:

I'm not saying it's impossible to get a smart TV or a setup box to run out of memory, we have that issue all the time; but except for a handful of bugs reported through the years there been not residents from previous visited pages.

Quote:

That's what I thought I said, most setup boxes uses the browser to render the UI permanently, some do however reboot when you enter standby but most don't (it's not until recently it's been a requirmenent to enter real standby at all, previously most just disabled video output and pretended to be in standby.)

Webkit don't do JS at all, that's JSCore or V8 depending on the branch you use, if you are aware of a situation where webkit leaks using Javascript, don't hesitate to mail me cause I'll certainly forward it do the development departments of each of the mentioned browser vendors if I can reproduce it. The problem is that most require a standalone page with example code, and that can sometimes be hard to deliver if you don't know exactly what cause it; but so far for each issue I encountered where I could produce an sample it's been resolved (however I have to admit I haven't reported more than approximately 2 memory related issues in 6 years, so to me they are rare).