Re: [webkit-dev] Proposal to limit the size of the captured exception stack

2017-03-16 Thread Brian Burg 

> On Mar 16, 2017, at 10:09 PM, Mark Lam  wrote:
> 
> Hi folks,
> 
> Currently, if we have an exception stack that is incredibly deep (especially 
> for a StackOverflowError), JSC may end up thrashing memory just to capture 
> the large stack trace in memory.This is bad for many reasons:
> 
> 1. the captured stack will take a lot of memory.

How much? What would be the new footprint with your suggestion below?

> 2. capturing the stack may take a long time (due to memory thrashing) and 
> makes for a bad user experience.
> 3. if memory availability is low, capturing such a large stack may result in 
> an OutOfMemoryError being thrown in its place.
>The OutOfMemoryError thrown there will also have the same problem with 
> capturing such a large stack.
> 4. most of the time, no one will look at the captured Error.stack anyway.
> 
> Since there isn’t a standard on what we really need to capture for 
> Error.stack, I propose that we limit how much stack we capture to a practical 
> size.  How about an Error.stack that consists of (1) the top N frames, (2) an 
> ellipses, and (3) the bottom M frames?  If the number of frames on the stack 
> at the time of capture  is less or equal to than N + M frames, then 
> Error.stack will just show the whole stack with no ellipses.  For example, if 
> N is 4 and M is 2, the captured stack will look something like this:
> 
>  foo10001
>  foo1
>  foo
>  foo9998
>  …
>  foo1
>  foo0
> 
> If we pick a sufficient large number for N and M (I suggest 100 each), I 
> think this should provide sufficient context for debugging uses of 
> Error.stack, while keeping an upper bound on how much memory and time we 
> throw at capturing the exception stack.

Web Inspector’s interface wouldn’t look too good with such a large call stack 
anyway, so this doesn’t degrade the current experience IMO. Maybe even 50+50 
would be fine. I’ve never seen a call stack that large in JS code (but then 
again, I don’t use fancy frameworks).

> My plan for implementing this is:
> 1. change Exception::finishCreation() to only capture the N and M frames, 
> plus possibly 1 ellipses placeholder in the between them.
> 2. change all clients of Exception::stack() to be able to recognize and 
> render the ellipses.
> 
> Does anyone object to doing this or have a compelling reason why this should 
> not be done?
> 
> Thanks.
> 
> Mark
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Proposal to limit the size of the captured exception stack

2017-03-16 Thread Mark Lam 
Hi folks,

Currently, if we have an exception stack that is incredibly deep (especially 
for a StackOverflowError), JSC may end up thrashing memory just to capture the 
large stack trace in memory.This is bad for many reasons:

1. the captured stack will take a lot of memory.
2. capturing the stack may take a long time (due to memory thrashing) and makes 
for a bad user experience.
3. if memory availability is low, capturing such a large stack may result in an 
OutOfMemoryError being thrown in its place.
The OutOfMemoryError thrown there will also have the same problem with 
capturing such a large stack.
4. most of the time, no one will look at the captured Error.stack anyway.

Since there isn’t a standard on what we really need to capture for Error.stack, 
I propose that we limit how much stack we capture to a practical size.  How 
about an Error.stack that consists of (1) the top N frames, (2) an ellipses, 
and (3) the bottom M frames?  If the number of frames on the stack at the time 
of capture  is less or equal to than N + M frames, then Error.stack will just 
show the whole stack with no ellipses.  For example, if N is 4 and M is 2, the 
captured stack will look something like this:

  foo10001
  foo1
  foo
  foo9998
  …
  foo1
  foo0

If we pick a sufficient large number for N and M (I suggest 100 each), I think 
this should provide sufficient context for debugging uses of Error.stack, while 
keeping an upper bound on how much memory and time we throw at capturing the 
exception stack.

My plan for implementing this is:
1. change Exception::finishCreation() to only capture the N and M frames, plus 
possibly 1 ellipses placeholder in the between them.
2. change all clients of Exception::stack() to be able to recognize and render 
the ellipses.

Does anyone object to doing this or have a compelling reason why this should 
not be done?

Thanks.

Mark



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

Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-16 Thread Ryosuke Niwa 
It looks like Windows testers haven't come back up:
https://build.webkit.org/builders/Apple%20Win%207%20Debug%20%28Tests%29
https://build.webkit.org/builders/Apple%20Win%207%20Release%20%28Tests%29

- R. Niwa


On Thu, Mar 16, 2017 at 7:37 PM, Ryosuke Niwa  wrote:
> Thanks!
>
> - R. Niwa
>
>
> On Thu, Mar 16, 2017 at 3:59 PM, Lucas Forschler  wrote:
>> I’ve re-triggered everything that landed after 2:00. This is r214068 through 
>> 214074.
>> r214075 was auto-triggered, as the build master was back online before it 
>> landed.
>>
>> Lucas
>>
>>> On Mar 16, 2017, at 3:44 PM, Lucas Forschler  wrote:
>>>
>>> I will ensure all commits that happen during transition get staged on the 
>>> new server.
>>> Lucas
>>>
 On Mar 16, 2017, at 2:52 PM, Ryosuke Niwa  wrote:

 Are you making the subversion server readonly meanwhile?

 It's not acceptable for our infrastructure to be down and letting
 people commit random things into the repository.
 - R. Niwa


 On Thu, Mar 16, 2017 at 2:40 PM, Ling Ho  wrote:
> Hello WebKit developers:
>
> We are continuing our transitioning of webkit.org servers today and
> tomorrow. Between 3pm and 4pm Pacific, we will be moving build.webkit.org.
> Please email us at ad...@webkit.org if you encounter any issue with your
> build bots after the transition.
>
> Thanks,
> ...
> ling
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-16 Thread Ryosuke Niwa 
Thanks!

- R. Niwa


On Thu, Mar 16, 2017 at 3:59 PM, Lucas Forschler  wrote:
> I’ve re-triggered everything that landed after 2:00. This is r214068 through 
> 214074.
> r214075 was auto-triggered, as the build master was back online before it 
> landed.
>
> Lucas
>
>> On Mar 16, 2017, at 3:44 PM, Lucas Forschler  wrote:
>>
>> I will ensure all commits that happen during transition get staged on the 
>> new server.
>> Lucas
>>
>>> On Mar 16, 2017, at 2:52 PM, Ryosuke Niwa  wrote:
>>>
>>> Are you making the subversion server readonly meanwhile?
>>>
>>> It's not acceptable for our infrastructure to be down and letting
>>> people commit random things into the repository.
>>> - R. Niwa
>>>
>>>
>>> On Thu, Mar 16, 2017 at 2:40 PM, Ling Ho  wrote:
 Hello WebKit developers:

 We are continuing our transitioning of webkit.org servers today and
 tomorrow. Between 3pm and 4pm Pacific, we will be moving build.webkit.org.
 Please email us at ad...@webkit.org if you encounter any issue with your
 build bots after the transition.

 Thanks,
 ...
 ling
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Introduce WebKit Android port

2017-03-16 Thread Michael Catanzaro 
Hi,

Is this just a code drop? Or will you be committing to its maintenance
and attempting to upstream it?

It's interesting regardless!

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] svn.webkit.org, git.webkit.org, trac.webkit.org and perf.webkit.org transition today on Friday at 10am PDT

2017-03-16 Thread Ling Ho 

Hello WebKit developers,

We have rescheduled our switch of svn.webkit.org and git.webkit.org for 
Friday (3/17) morning, between 10 and 11am PDT. We will also be moving 
trac.webkit.org and perf.webkit.org during the same time.


The current svn repository will be made read-only at 10am. We will send 
out a notice when commit can be made again.


Thanks,
...
ling

On 3/13/17 3:02 PM, Lucas Forschler wrote:

Hello WebKit,

Both svn.webkit.org  and the git.webkit.org 
 mirror will be transitioning to new hardware 
this evening.


For svn.webkit.org , our plan is to make the 
current repository read only between 6:00 and 6:30. As soon as the DNS 
change takes effect, you should be able to commit to the new server as 
expected, with no changes. We are using the same UUID and SSL 
certificate, so your source checkout should not complain. I’ll 
follow-up with another reminder shortly before we make any changes.


Thanks,
Lucas



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


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

Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-16 Thread Lucas Forschler 
I’ve re-triggered everything that landed after 2:00. This is r214068 through 
214074.
r214075 was auto-triggered, as the build master was back online before it 
landed.

Lucas

> On Mar 16, 2017, at 3:44 PM, Lucas Forschler  wrote:
> 
> I will ensure all commits that happen during transition get staged on the new 
> server.
> Lucas
> 
>> On Mar 16, 2017, at 2:52 PM, Ryosuke Niwa  wrote:
>> 
>> Are you making the subversion server readonly meanwhile?
>> 
>> It's not acceptable for our infrastructure to be down and letting
>> people commit random things into the repository.
>> - R. Niwa
>> 
>> 
>> On Thu, Mar 16, 2017 at 2:40 PM, Ling Ho  wrote:
>>> Hello WebKit developers:
>>> 
>>> We are continuing our transitioning of webkit.org servers today and
>>> tomorrow. Between 3pm and 4pm Pacific, we will be moving build.webkit.org.
>>> Please email us at ad...@webkit.org if you encounter any issue with your
>>> build bots after the transition.
>>> 
>>> Thanks,
>>> ...
>>> ling
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

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

Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-16 Thread Lucas Forschler 
I will ensure all commits that happen during transition get staged on the new 
server.
Lucas

> On Mar 16, 2017, at 2:52 PM, Ryosuke Niwa  wrote:
> 
> Are you making the subversion server readonly meanwhile?
> 
> It's not acceptable for our infrastructure to be down and letting
> people commit random things into the repository.
> - R. Niwa
> 
> 
> On Thu, Mar 16, 2017 at 2:40 PM, Ling Ho  wrote:
>> Hello WebKit developers:
>> 
>> We are continuing our transitioning of webkit.org servers today and
>> tomorrow. Between 3pm and 4pm Pacific, we will be moving build.webkit.org.
>> Please email us at ad...@webkit.org if you encounter any issue with your
>> build bots after the transition.
>> 
>> Thanks,
>> ...
>> ling
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-16 Thread Ryosuke Niwa 
Are you making the subversion server readonly meanwhile?

It's not acceptable for our infrastructure to be down and letting
people commit random things into the repository.
- R. Niwa


On Thu, Mar 16, 2017 at 2:40 PM, Ling Ho  wrote:
> Hello WebKit developers:
>
> We are continuing our transitioning of webkit.org servers today and
> tomorrow. Between 3pm and 4pm Pacific, we will be moving build.webkit.org.
> Please email us at ad...@webkit.org if you encounter any issue with your
> build bots after the transition.
>
> Thanks,
> ...
> ling
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] build.webkit.org transition today at 3pm PDT

2017-03-16 Thread Ling Ho 

Hello WebKit developers:

We are continuing our transitioning of webkit.org servers today and 
tomorrow. Between 3pm and 4pm Pacific, we will be moving 
build.webkit.org. Please email us at ad...@webkit.org if you encounter 
any issue with your build bots after the transition.


Thanks,
...
ling
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Port For Android

2017-03-16 Thread Sergio Villar Senin 
O Mar, 07-03-2017 ás 20:07 -0500, Patrick Wright escribiu:
> 
> However, in the source code of android. There is an implementation of
> Webkit show here: https://developer.android.com/reference/android/web
> kit/package-summary.html . it is just very slow and restrictive. 

That's the Android WebView which is based on Blink (Chromium). The
architecture is completely different to desktop Chromium though due to
platform limitations in Android.

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev