RE: [sv-ec] Re: Mailbox - null return

I disagree with the blind characterization of a memory allocation
problem as a 'gross user error'.

Yes, a gross user error can cause such a problem. But so also can code
which looks perfectly reasonable at first, but contains a subtle catch.
Maybe a user error, but not a gross one. Such cases show up occasionally
on the Verification Guild forum, for example.

Beyond that, all tools have bugs, and sometimes those bugs cause such
problems. The bug databases of all tool vendors are full of such cases.

By the way, Joel Spolsky (http://www.joelonsoftware.com/ , highly
recommended) bewails the use of languages like Java for teaching
programming. He says this causes programmers to be unaware of the
fundamentals and unaware of what happens behind the curtains, causing
people to write horribly inefficient code. See
http://www.joelonsoftware.com/printerFriendly/articles/ThePerilsofJavaSc
hools.html . 

So here, for example, in 7.7, we tell people that garbage collection in
SV is automatic and you avoid the "bane of C++ programmers". Well maybe
you won't have memory leaks that are your fault, but that does not mean
you don't mean to know something about memory allocation. But that is
the impression created by the LRM. That does not mean I am against
automatic garbage collection. But it is not the panacea it is sometimes
promoted as.

Shalom

> -----Original Message-----
> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
On
> Behalf Of Neil Korpusik
> Sent: Tuesday, May 23, 2006 11:26 PM
> To: Rich, Dave
> Cc: Arturo Salz; sv-ec@server.eda.org
> Subject: Re: [sv-ec] Re: Mailbox - null return
> 
> Dave,
> 
> My comments are below.
> 
> Neil
> 
> 
> 
> Rich, Dave wrote On 05/10/06 12:35,:
> > Arturo,
> >
> >
> >
> > OK, 'gross /user error in/ simulation' would have been a better
choice
> > of words.
> >
> >
> > You, Steve, and I all seem to be in agreement that a mailbox is just
a
> > class and there's no reason to treat its allocation any differently.
> So
> > any text about *new* does not belong in the section about mailboxes
> (and
> > I now see the same text in semaphores that should also be removed).
It
> > belongs in section 7.7 class constructors.
> 
> [Neil]
>  I agree that a mailbox should be thought of as a built-in class. I
also
> have
> no problem moving verbiage about new() returning null to 7.7.
> 
> >
> >
> >
> > If you want *new* to return null, then you must also add the ability
> to
> > test the result of *super.new*, which you can't do right now.
> 
> [Neil]
> I don't see the need for this. As long as the handle for the object
> being constructed by the user code is set to null, aren't we ok? Users
> would just need to check the handle returned for the extended class. I
> am
> assuming that the handle returned for the extended class would be set
to
> null if a call to super.new() returned null. Maybe you are assuming
> some other behavior.
> 
> >
> >
> >
> > And what is the point of returning null? What assurances would the
> user
> > have in continuing to execute code beyond that point?
> 
> [Neil]
> One good reason for returning null is to allow the user to check for
the
> null value and print out a useful message to allow the problem to be
> debugged. If the LRM simply says that applications need to print
> an error message, there is no guarantee that such a message would be
> useful for debugging the testbench.
> 
> How would one go about debugging a memory allocation problem when we
> only
> have the following output to go on?
> 
> ERROR: out of memory
> 
> 
> >
> >
> >
> > Dave
> >
> >
> >
> >
> >
> >
----------------------------------------------------------------------
> --
> >
> > *From:* Arturo Salz [mailto:Arturo.Salz@synopsys.com]
> > *Sent:* Wednesday, May 10, 2006 11:56 AM
> > *To:* Rich, Dave; sv-ec@eda.org
> > *Subject:* RE: [sv-ec] Re: Mailbox - null return
> >
> >
> >
> > Dave,
> >
> >
> >
> > You write in this item:
> >
> > It would be a gross simulation error if there are not enough
resources
> > to allocate an object.
> >
> > I disagree. Running out of memory is not a simulation error. A
trivial
> > user coding error can cause the system to run out of memory, and the
> > simulator cannot guarantee that it will always have enough resources
> to
> > satisfy the request. For example, the following snippet will
> eventually
> > cause the system to run out of memory:
> >
> >
> >
> >    mailbox m[$];
> >
> >    always @(clk) begin
> >
> >       mailbox m1 = new();
> >
> >       m.insert( 0, m1);
> >
> >    end
> >
> >
> >
> > As Steve Sharp pointed out, a mailbox is a class and there is no
> reason
> > why its allocation should be handled differently from any other
> > dynamically allocated object. The only alternative would be to turn
> > allocation failures into a hard error for all dynamic objects, and
I'm
> > not sure that is warranted.
> >
> >
> >
> >             Arturo
> >
> >
> >
> >
----------------------------------------------------------------------
> --
> >
> > *From:* owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] *On Behalf
Of
> > *Rich, Dave
> > *Sent:* Wednesday, May 10, 2006 9:00 AM
> > *To:* sv-ec@eda.org
> > *Subject:* RE: [sv-ec] Re: Mailbox - null return
> >
> >
> >
> > Mehdi,  Now you do need to take action.
> >
> >
> >
> > Submitted as
http://www.eda.org/svdb/bug_view_page.php?bug_id=0001459
> > with a proposal.
> >
> >
> >
> >
----------------------------------------------------------------------
> --
> >
> > *From:* owner-sv-ec@server.eda.org
[mailto:owner-sv-ec@server.eda.org]
> > *On Behalf Of *Brad Pierce
> > *Sent:* Tuesday, May 09, 2006 6:38 PM
> > *To:* sv-ec@server.eda.org
> > *Cc:* Maidment, Matthew R
> > *Subject:* [sv-ec] Re: Mailbox - null return
> >
> >
> >
> > In http://www.eda.org/sv-bc/hm/4469.html , Dave explains to the
SV-BC
> > about an apparent mailbox erratum found by Cliff.  But mailboxes are
> an
> > SV-EC issue.
> >
> >
> >
> > Could the SV-EC please look into this issue, and if, as Dave
> > convincingly argues, it is truly an erratum, take ownership of it?
> >
> >
> >
> > Thanks,
> >
> >
> >
> > -- Brad
> >
> 
> --
> ---------------------------------------------------------------------
> Neil Korpusik                                     Tel: 408-720-4852
> Senior Staff Engineer                             Fax: 408-720-4850
> Frontend Technologies - ASICs & Processors (FTAP)
> Sun Microsystems
> email: neil.korpusik@sun.com
> ---------------------------------------------------------------------