From:         dgil@ipsaint.ipsa.reuter.COM (Gillett, David)
Subject:      Re: j 5.1, pc, 386
Reply-To:     dgil@ipsaint.ipsa.reuter.COM (Gillett, David)
Organization: Reuters Information Services (Canada)
Date:         28 Sep 92 04:00:04 UT


-----------Message forwarded from IPSA Mailbox-------------


no. 6606754 filed  3.32.20  mon 28 sep 1992
from dgil
to   uclapl
subj Re: j 5.1, pc, 386
ref  6606165

     We're so close to agreeing, and yet we seem to be managing to talk around
each other.

a.  I mention that 3 out of 4 of Mr. Bernecky's suggestions fail to address
    heap fragmentation.  He restates, at length, the fourth suggestion.  I
    thought that it was already clear that the fourth suggestion *does* address
    fragmentation; I agree totally that this is the way that real systems which
    avoid fragmentation problems manage to do it.

2.
> The response was directed at the "how do I get a Quadwa facility in J?"
> question.  As usual in the language design biz, the person who "wants
> facility X" usually has another, unasked question about another, unspecified,
> problem.
    This is normal throughout software engineering, not just in language
  design....
> In this case, it's heap fragmentation and virtual storage problems.
    Is it?  I would have thought it was something like:  How can my program
  make run-time choices between size-intensive and speed-intensive approaches
  based on available resources?  I do agree that simply implementing an exact
  analogue of quadWA is not the answer, but I think we disagree about the real
  question.

3.
> "This application runs in a 2 megabyte workspace"....
    Okay, so this suggests that instead of allocating all available memory to
  the J application, we let the programmer specify how much to allocate, and
  quadWAprime can report how much of that space is left.  So far so good.
    Two questions immediately suggest themselves:  What does J do if the
  specified space is not available?  And what if the programmer fails to
  specify a size -- what does J assume, and what does quadWAprime report?
    So this solves some problems, and introduces others.

3.
> In a real system, there is no guarantee that that approach is race free.
    True.  I was trying to avoid simply making alloc() and free() primitives
  in J.
> Since malloc returns a "worked/didn't work" signal anyway, what's the point?
    Well, I gave my reading of the "real question" above, so I think it's
  obvious where I see the use.  malloc(), in the "worked" case, has a nasty
  side effect -- that the memory in question is now reserved -- which the
  primitive which I was suggesting need not preserve.  Obviously, the race
  condition to which you allude can be avoided by *requiring* that the
  memory be reserved, but that also requires some way, at the "J code" level,
  to tell some arbitrary primitive down the line to use that reserved space
  instead of malloc'ing afresh.  I don't care to suggest a syntax for *that*.

  I don't think that we're in substantial disagreement about the
characteristics of different approaches to heap-management.  I think that
your implicit suggestion of a mechanism for pre-reserving workspace could be
fleshed out sufficiently to address the problem as I perceive it.  It might be
useful if the original poster were to expound upon how he would like to be able
to use the information which quadWA reports.

                                      Dave Gillett


-----------------------------------------------------------
This posting is forwarded from an internal Reuters mailbox.
No statement or opinion contained herein should be taken as
being Reuters policy, or even as being approved by Reuters,
in any way.
Newsgroups: comp.lang.apl