RE: [sv-ec] Re: [sv-bc] ballot comment on static reference arguments

From: Rich, Dave <Dave_Rich_at_.....>
Date: Fri Apr 08 2005 - 16:43:28 PDT
> -----Original Message-----
> From: Steven Sharp [mailto:sharp@cadence.com]
> Sent: Friday, April 08, 2005 4:26 PM
> To: sharp@cadence.com; sv-bc@eda.org; Brad.Pierce@synopsys.com; Rich,
Dave
> Cc: sv-ec@eda.org
> Subject: RE: [sv-ec] Re: [sv-bc] ballot comment on static reference
> arguments
> 
> 
> >In general, static tasks are a problem for garbage collection, even
with
> >out the ref argument. If I pass a class handle to an argument of a
> >static task/function, that static argument retains the handle after
the
> >task/function returns.
> 
> Have you proposed a solution for that issue as well?
[DR>] Not here
> 
> 
> >If you just disallow hierarchical references to the static argument,
> >that doesn't change the fact that the argument still contains the
> >reference after the task exits (or you would have to add more
language
> >that says that it doesn't).
> 
> If you can't access the value, does it matter whether it is still
there?
> (If a tree falls in the forest...)  If you can access it via PLI or a
> user interface, perhaps so.  However, as you say, such references
could
> be specified to be NULLed out on exit.
[DR>] Why make things more complicated than they need to be.
> 
> 
> >So the simpler solution is to just forbid declaring a static task in
> >this case, which is the direction we want users to take anyway.
> 
> I'm not sure that "we" includes everyone.  Static tasks offer some
> advantages, such as efficiency.  Other new language features that are
> effectively requiring automatics to be garbage-collected are
increasing
> that efficiency gap.
[DR>] "We" were the people at the meeting.
> 
> 
> >BTW, you can't  declare a static argument to an automatic task.
> 
> Well, that avoids that issue anyway.
> 
> 
> Steven Sharp
> sharp@cadence.com
Received on Fri Apr 8 16:43:51 2005

This archive was generated by hypermail 2.1.8 : Fri Apr 08 2005 - 16:43:55 PDT