[Webkit-unassigned] [Bug 149556] New: Improve binding of JSBuiltinConstructor classes

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=149556

            Bug ID: 149556
           Summary: Improve binding of JSBuiltinConstructor classes
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebCore Misc.
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: youennf at gmail.com

Following on bug 149522 discussion, we might want to improve the binding generator.

(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > > > > Source/WebCore/bindings/js/JSDOMWrapper.h:54
> > > > > +    virtual ~DummyDOMClass() { }
> > > > 
> > > > Not sure why this is needed. Do we need the class to seem polymorphic for
> > > > some reason?
> > > 
> > > This is required by RefCounted IIRC.
> > 
> > RefCounted itself definitely does *not* require that the class be
> > polymorphic so it doesn’t require a virtual destructor.
> > 
> > We need to make the destructor virtual if we are going to deref or delete
> > these objects in a polymorphic way, using a pointer to a base class. I think
> > you could revisit this and make the class both "final" and not define a
> > virtual destructor.
> 
> Thanks for the information.
> 
> > 
> > You also talked about cleaning things up further so the class isn’t needed
> > at all; if you do that this won’t matter at all.
> > 
> > If we do need to keep this class, then we can do another trick for better
> > efficiency:
> > 
> >     class $className {
> >     public:
> >         static Ref<$className> create() { return adoptRef(singleton());
> > }\n"); 
> >         static void ref() { }
> >         static void deref() { }
> >     private:
> >         static $className& singleton() { static NeverDestroyed<$className>
> > singleton; return singleton; }
> >     };
> > 
> > No memory allocation, no incrementing and decrementing reference counts.
> 
> Yes, that is one approach I thought of.
> It requires bypassing JSDOMGlobalObject wrapper cache, which is another
> efficiency bonus.
> 
> We may also want to use a single singleton for all builtin classes.
> 
> To go further, we may want to skip generation of some needless code (toJS,
> releaseImpl...).
> 
> Choice may be guided by the added complexity to the binding generator.
> I plan to take some time on this once the JS builtin architecture is ready
> to implement ReadableStream and WritableStream.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20150925/5b39d8c7/attachment.html>