<p dir="auto">While working on a way to address <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="51276051" data-permission-text="Title is private" data-url="https://github.com/golang/go/issues/101" data-hovercard-type="issue" data-hovercard-url="/golang/go/issues/101/hovercard" href="https://github.com/golang/go/issues/101">#101</a>, it was discovered that some of the functions, constants, and structures offered in go/doc/comment.go are useful for parsing Go source code comments.</p>
<p dir="auto">In particular, blocks(), block, op, opPara, opHead, and opPre.</p>
<p dir="auto">Currently, consumers wanting to generate their own documentation or process Go source code are left with duplicating the existing logic found in go/doc/comment.go or adding special-case logic to that file itself for specific formats (undesirable).  I would like to suggest that the aforementioned items be made public, or moved to a more suitable package for re-use by others.</p>
<p dir="auto">Doing so would make it easier to add support for the generation of new documentation formats, such as manual pages, etc. and would likely provide a cleaner result.</p>
<p dir="auto">If the desire is to keep these items where they are today, I would rename them as follows:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content=" blocks -&gt; Blocks
 block -&gt; Block
   block.op -&gt; block.Op
   block.lines -&gt; block.Lines
 op -&gt; Op
 opPara -&gt; OpPara
 opHead -&gt; OpHead
 opPre -&gt; OpPre"><pre class="notranslate"><code class="notranslate"> blocks -&gt; Blocks
 block -&gt; Block
   block.op -&gt; block.Op
   block.lines -&gt; block.Lines
 op -&gt; Op
 opPara -&gt; OpPara
 opHead -&gt; OpHead
 opPre -&gt; OpPre
</code></pre></div>
<p dir="auto">I am open to counter-suggestions as to how this logic should be exposed and I am willing to perform the work requested.</p>
<p dir="auto">This bug was filed at the request of <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/adg/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/adg">@adg</a></p>
<p dir="auto">by <strong>peter.waller</strong>:</p>
<pre class="notranslate">This issue was discussed in this post on golang-dev:
<a href="https://groups.google.com/forum/?fromgroups=#" rel="nofollow">https://groups.google.com/forum/?fromgroups=#</a>!topic/golang-dev/xI7RIjkSeqk

The heap scavenger is hard-coded to free up memory spans which are unused for longer
than five minutes. For some applications this is unacceptable: in my case I need go
memory to become available to the operating system in short order (~10s).

The current proposed solution on the ML is to introduce a runtime function to run the
heap scavenger manually. This may require modifying the existing scavenger quite a bit.

MHeap_Scavenger code:
<a href="http://code.google.com/p/go/source/browse/src/pkg/runtime/mheap.c?spec=svn0a3866d6cc6b16e44ba6e8fb631a471ce81ca412&amp;" rel="nofollow">http://code.google.com/p/go/source/browse/src/pkg/runtime/mheap.c?spec=svn0a3866d6cc6b16e44ba6e8fb631a471ce81ca412&amp;</a>;name=b96e722aad5a&amp;r=0a3866d6cc6b16e44ba6e8fb631a471ce81ca412#349</pre>