On Tue, May 10, 2016 at 9:50 AM, Nick Fitzgerald
wrote:
> Or, if we don't want to boil too many oceans and have something closer to
> our usage of bool and not worry about wrapping types:
>
> class Result
> {
> public:
> enum class Type : uint32_t
> {
> Ok,
> Oom,
>
On 05/09/2016 04:32 PM, Nicholas Nethercote wrote:
On Sat, Apr 23, 2016 at 9:29 AM, Nicholas Nethercote
wrote:
one thing I've been thinking about is using
MOZ_WARN_UNUSED_RESULT more.
It isn't useful for the "return null on failure" case, because the
result will always be used even if you forge
If we are going to leave bool behind, I think we should use something
Rustic:
template
class MOZ_MUST_USE_TYPE Result : public mozilla::Variant
{
public:
// Helper methods here...
explicit operator bool () { return is(); }
// Etc...
};
Or, if we don't want to boil too many ocean
On Sat, Apr 23, 2016 at 9:29 AM, Nicholas Nethercote
wrote:
>
> one thing I've been thinking about is using
> MOZ_WARN_UNUSED_RESULT more.
> It isn't useful for the "return null on failure" case, because the
> result will always be used even if you forget the check. But it is
> useful for the "ret
In gecko, "large" allocations (anything that is under site control) are
supposed to be fallible and have at least some kind of sane fallback path.
This is not universally true currently but it is the goal.
Small allocations in gecko are fatal (crashy), and so I don't think there's
any point in mak
On Sat, Apr 23, 2016 at 1:29 AM, Nicholas Nethercote wrote:
> I fully admit to not doing much JS engine work these days and I don't
> know about this ReportOutOfMemory behaviour. But isn't the "return
> null/false" pattern still heavily used? Looking quickly through
> jsapi.cpp it sure seems to b
On Fri, Apr 22, 2016 at 3:16 AM, Jan de Mooij wrote:
>
> I think in 'ancient' SpiderMonkey, we used to deal with OOM by returning
> null/false. Other exceptions were reported to the JSContext.
>
> Then we changed this: ReportOutOfMemory now throws the "out of memory"
> string. This allowed scripts
Very interesting to see experience reports counter to my intuition. If
looked at from the UX perspective, indeed we should attempt to gracefully
handle OOM since the entirety of JavaScript is optional for a page. The
last point is debatable in today's web though.
On Fri, Apr 22, 2016 at 3:20 AM, N
On 04/21/2016 09:05 PM, Shu-yu Guo wrote:
The first is ergonomic. I want phased workloads like parsing + BCE and JIT
compiling to be completely infallible. The allocation pattern of compilers
is a series of many small allocations. I'd like to just allocate a huge
buffer inside a LifoAlloc-like al
You're right, I was speaking sloppily. By "infallible" I mean construction
of the AST should not need to be null-checked.
I would like to allocate a tremendous amount of virtual memory up front
such that we can just crash. I take back what I said about 32bit
fragmentation, this approach would fail
On Thu, Apr 21, 2016 at 5:53 PM, Jason Orendorff
wrote:
> On Thu, Apr 21, 2016 at 4:00 PM, Bobby Holley
> wrote:
> > Note that a while back I added a mechanism where you can easily ban
> script from ever running again in a compartment - see [1] for a usage
> example.
> >
> > So this should be a
On Thu, Apr 21, 2016 at 4:00 PM, Bobby Holley wrote:
> Note that a while back I added a mechanism where you can easily ban
script from ever running again in a compartment - see [1] for a usage
example.
>
> So this should be a trivial (and probably worthwhile) patch.
Agreed!
Separately from that
I want to understand your beefs before really responding...
On Thu, Apr 21, 2016 at 4:05 PM, Shu-yu Guo wrote:
> The first is ergonomic. I want phased workloads like parsing + BCE and JIT
> compiling to be completely infallible.
>
What do you mean by "infallible" here? To me it seems like virtu
I got two beefs.
The first is ergonomic. I want phased workloads like parsing + BCE and JIT
compiling to be completely infallible. The allocation pattern of compilers
is a series of many small allocations. I'd like to just allocate a huge
buffer inside a LifoAlloc-like allocator in the beginning a
Note that a while back I added a mechanism where you can easily ban script
from ever running again in a compartment - see [1] for a usage example.
So this should be a trivial (and probably worthwhile) patch.
[1]
https://hg.mozilla.org/mozilla-central/file/10f66b316457/dom/base/nsGlobalWindow.cpp#
Due to 32-bit + fragmentation, even "modest" allocations of 300mb can
regularly fail, so it seems important to allow apps to gracefully
handle these situations and put up some UI that informs the user. You
can also consider cases where the allocation failure doesn't mean the
whole app is dead, jus
On Thu, Apr 21, 2016 at 2:23 PM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:
> On 04/21/2016 05:16 PM, Jan de Mooij wrote:
>
>> Is our only option doubling down on these fuzz bugs and adding more
>> assertions, or can we do better with static analysis, the type system,
>> annotation
> Dealing with OOM everywhere is complicated enough, but I think the
>>> exception part makes it even more difficult to get right.
>>>
>>
...Incidentally, I still think OOM shouldn't be catchable, just as a matter
of sane language behavior. It's too likely to re-fail during catch/finally
blocks.
L
On 04/21/2016 05:16 PM, Jan de Mooij wrote:
Is our only option doubling down on these fuzz bugs and adding more
assertions, or can we do better with static analysis, the type system,
annotations, something?
From the type system point of view, I think we could add a type to
distinguish the Allo
On Thu, Apr 21, 2016 at 1:06 PM, Jason Orendorff
wrote:
>
> Dealing with OOM everywhere is complicated enough, but I think the
>> exception part makes it even more difficult to get right.
>>
>
> I don't think it makes it appreciably harder. It does mean that bugs cause
>
I meant to say here that
On Thu, Apr 21, 2016 at 12:16 PM, Jan de Mooij wrote:
> OOM fuzzing has been quite effective, but it feels like a game of
> whack-a-mole. It also doesn't help us find and fix similar bugs outside
> SpiderMonkey.
>
Agreed.
Dealing with OOM everywhere is complicated enough, but I think the
> exce
Hi,
I think in 'ancient' SpiderMonkey, we used to deal with OOM by returning
null/false. Other exceptions were reported to the JSContext.
Then we changed this: ReportOutOfMemory now throws the "out of memory"
string. This allowed scripts to catch OOMs, for instance when allocating
large ArrayBuff
22 matches
Mail list logo
