<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div class="markdown-here-wrapper" data-md-url="" style="">
<p style="margin: 0px 0px 1.2em !important;">On 05/06/2024 18:25,
Pedro Lamarão wrote:</p>
<p style="margin: 0px 0px 1.2em !important;"></p>
<div class="markdown-here-exclude">
<p></p>
<blockquote type="cite" cite="mid:CAC8PkgEtB+Uw4RwPsLDBeO-By_UZC_5mBmje6DKnkKjC_N7PQQ@mail.gmail.com">Also,
as this discussion suggests, what appears to be a universal
interface may actually not be universal at all, and perhaps it
is best to have libraries define their own allocator
interfaces and see what emerges from that.</blockquote>
<p></p>
</div>
<p style="margin: 0px 0px 1.2em !important;"></p>
<p style="margin: 0px 0px 1.2em !important;">This is the thing we
keep (re)learning when thinking about allocators in FFM. It is
tempting to hardwire something to cater specific needs, but in
reality specific libraries will work with very specific set of
constraints, so our best bet is to somehow support such things
to be built on top.</p>
<p style="margin: 0px 0px 1.2em !important;">Now, this is
orthogonal to the original question which was about advertizing
zeroing properties of an allocator. What we’re seeing there is
the (unavoidable) consequence of the (unavoidable) decision of
not exposing (by default, at least) non-zeroing memory
allocation primitives. E.g. it is easy to write a zeroing
allocator if you have a non-zeroing one (as the latter is
clearly more primitive than the former). But it wouldn’t have
been safe to expose non-zeroing allocators in the front door
allocation API. This set of constraints has led us to
SegmentAllocator being the way it is today, where we make no
assumption on what the “correct” behavior for
SegmentAllocator::allocate should be. For Arenas that are
provided by the JDK, the answer has to be “zeroing”. But users
are (and should!) be able to define allocators/arenas that do no
zero, if they have compelling use cases where zeroing would add
too much overhead.</p>
<p style="margin: 0px 0px 1.2em !important;">Should we have an
extra method in SegmentAllocator which states what’s the zeroing
policy for the allocator?</p>
<p style="margin: 0px 0px 1.2em !important;">It’s certainly cheap
to add, but:</p>
<ul style="margin: 1.2em 0px;padding-left: 2em;">
<li style="margin: 0.5em 0px;">users will forget to override
that (esp. given SegmentAllocator is a functional interface)</li>
<li style="margin: 0.5em 0px;">it only addresses <em>one</em>
dimension in which a given allocator is special - are there
others? (e.g. disjointness of returned segments, etc)</li>
<li style="margin: 0.5em 0px;">another approach could be for
clients that do want guaranteed zeroing to always call
MS::fill, and rely on C2 to eliminate the redundant memset
(after all Unsafe::setMemory is an intrinsics). This is hard
to achieve, but would probably lead to a better long-term
path, where we can stop worrying about duplicate zeroing (as
happens for on-heap arrays). At this point having the
predicate on <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">SegmentAllocator</code>
woudn’t add too much.</li>
</ul>
<p style="margin: 0px 0px 1.2em !important;">For all these
reasons, I’m slightly against adding new methods to
SegmentAllocator. Of course if this requests turned out to be a
very common one I could reconsider of course.</p>
<p style="margin: 0px 0px 1.2em !important;">Last, note that
there’s a workaround, even though it might not look too pretty.
Let’s say that you know that you only allocate 1024 bytes tops.
Then you can do like so:</p>
<pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code class="hljs language-java" style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;display: block; overflow-x: auto; padding: 0.5em; color: rgb(51, 51, 51); background: rgb(248, 248, 248); -moz-text-size-adjust: none;"><span class="hljs-function">MemorySegment <span class="hljs-title" style="color: rgb(153, 0, 0); font-weight: bold;">allocateAndZero</span><span class="hljs-params">(SegmentAllocator allocator, <span class="hljs-keyword" style="color: rgb(51, 51, 51); font-weight: bold;">long</span> size)</span> </span>{
<span class="hljs-class"><span class="hljs-keyword" style="color: rgb(51, 51, 51); font-weight: bold;">class</span> <span class="hljs-title" style="color: rgb(153, 0, 0); font-weight: bold;color: rgb(68, 85, 136); font-weight: bold;">Holder</span> </span>{
<span class="hljs-keyword" style="color: rgb(51, 51, 51); font-weight: bold;">static</span> MemorySegment ZERO = MemorySegment.ofArray(<span class="hljs-keyword" style="color: rgb(51, 51, 51); font-weight: bold;">new</span> <span class="hljs-keyword" style="color: rgb(51, 51, 51); font-weight: bold;">byte</span>[<span class="hljs-number" style="color: rgb(0, 128, 128);">1024</span>]);
}
<span class="hljs-comment" style="color: rgb(153, 153, 136); font-style: italic;">// todo: check that `size < 1024`</span>
<span class="hljs-keyword" style="color: rgb(51, 51, 51); font-weight: bold;">return</span> allocator.allocateFrom(JAVA_BYTE, Holder.ZERO, JAVA_BYTE, <span class="hljs-number" style="color: rgb(0, 128, 128);">0</span>, size);
}
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">Note that this uses <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">allocateFrom</code>
to allocate a memory segment of given size, and then bulk copy
(a part of) the “zero segment” on top of it. This won’t perform
double zeroing, because <code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;">SegmentAllocator::allocateFrom</code>
tries to avoid that also. The only difference is that we’re
using “Unsafe::copyMemory” instead of “Unsafe::setMemory” to
zero the memory (but both should perform roughly the same, as
they are both intrinsics that support vectorized instructions).
It’s not pretty, but maybe could be ok while we wait for deeper
“duplicate zero memset” avoidance?</p>
<p style="margin: 0px 0px 1.2em !important;">Maurizio</p>
<div title="MDH:PHA+PGJyPjwvcD48ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDA1LzA2LzIwMjQgMTg6
MjUsIFBlZHJvIExhbWFyw6NvIHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjaXRlPSJtaWQ6Q0FDOFBrZ0V0QitVdzRSd1BzTERCZU8tQnlfVVpDXzVtQm1qZTZES25rS2pD
X043UFFRQG1haWwuZ21haWwuY29tIj5BbHNvLCBhcyB0aGlzIGRpc2N1c3Npb24gc3VnZ2VzdHMs
IHdoYXQgYXBwZWFycyB0byBiZSBhIHVuaXZlcnNhbCAKaW50ZXJmYWNlIG1heSBhY3R1YWxseSBu
b3QgYmUgdW5pdmVyc2FsIGF0IGFsbCwgYW5kIHBlcmhhcHMgaXQgaXMgYmVzdCAKdG8gaGF2ZSBs
aWJyYXJpZXMgZGVmaW5lIHRoZWlyIG93biBhbGxvY2F0b3IgaW50ZXJmYWNlcyBhbmQgc2VlIHdo
YXQgCmVtZXJnZXMgZnJvbSB0aGF0LjwvYmxvY2txdW90ZT48cD5UaGlzIGlzIHRoZSB0aGluZyB3
ZSBrZWVwIChyZSlsZWFybmluZyB3aGVuIHRoaW5raW5nIGFib3V0IGFsbG9jYXRvcnMgaW4gRkZN
LiBJdCBpcyB0ZW1wdGluZyB0byBoYXJkd2lyZSBzb21ldGhpbmcgdG8gY2F0ZXIgc3BlY2lmaWMg
bmVlZHMsIGJ1dCBpbiByZWFsaXR5IHNwZWNpZmljIGxpYnJhcmllcyB3aWxsIHdvcmsgd2l0aCB2
ZXJ5IHNwZWNpZmljIHNldCBvZiBjb25zdHJhaW50cywgc28gb3VyIGJlc3QgYmV0IGlzIHRvIHNv
bWVob3cgc3VwcG9ydCBzdWNoIHRoaW5ncyB0byBiZSBidWlsdCBvbiB0b3AuPC9wPjxwPk5vdywg
dGhpcyBpcyBvcnRob2dvbmFsIHRvIHRoZSBvcmlnaW5hbCBxdWVzdGlvbiB3aGljaCB3YXMgYWJv
dXQgYWR2ZXJ0aXppbmcgemVyb2luZyBwcm9wZXJ0aWVzIG9mIGFuIGFsbG9jYXRvci4gV2hhdCB3
ZSdyZSBzZWVpbmcgdGhlcmUgaXMgdGhlICh1bmF2b2lkYWJsZSkgY29uc2VxdWVuY2Ugb2YgdGhl
ICh1bmF2b2lkYWJsZSkgZGVjaXNpb24gb2Ygbm90IGV4cG9zaW5nIChieSBkZWZhdWx0LCBhdCBs
ZWFzdCkgbm9uLXplcm9pbmcgbWVtb3J5IGFsbG9jYXRpb24gcHJpbWl0aXZlcy4gRS5nLiBpdCBp
cyBlYXN5IHRvIHdyaXRlIGEgemVyb2luZyBhbGxvY2F0b3IgaWYgeW91IGhhdmUgYSBub24temVy
b2luZyBvbmUgKGFzIHRoZSBsYXR0ZXIgaXMgY2xlYXJseSBtb3JlIHByaW1pdGl2ZSB0aGFuIHRo
ZSBmb3JtZXIpLiBCdXQgaXQgd291bGRuJ3QgaGF2ZSBiZWVuIHNhZmUgdG8gZXhwb3NlIG5vbi16
ZXJvaW5nIGFsbG9jYXRvcnMgaW4gdGhlIGZyb250IGRvb3IgYWxsb2NhdGlvbiBBUEkuIFRoaXMg
c2V0IG9mIGNvbnN0cmFpbnRzIGhhcyBsZWQgdXMgdG8gU2VnbWVudEFsbG9jYXRvciBiZWluZyB0
aGUgd2F5IGl0IGlzIHRvZGF5LCB3aGVyZSB3ZSBtYWtlIG5vIGFzc3VtcHRpb24gb24gd2hhdCB0
aGUgImNvcnJlY3QiIGJlaGF2aW9yIGZvciBTZWdtZW50QWxsb2NhdG9yOjphbGxvY2F0ZSBzaG91
bGQgYmUuIEZvciBBcmVuYXMgdGhhdCBhcmUgcHJvdmlkZWQgYnkgdGhlIEpESywgdGhlIGFuc3dl
ciBoYXMgdG8gYmUgInplcm9pbmciLiBCdXQgdXNlcnMgYXJlIChhbmQgc2hvdWxkISkgYmUgYWJs
ZSB0byBkZWZpbmUgYWxsb2NhdG9ycy9hcmVuYXMgdGhhdCBkbyBubyB6ZXJvLCBpZiB0aGV5IGhh
dmUgY29tcGVsbGluZyB1c2UgY2FzZXMgd2hlcmUgemVyb2luZyB3b3VsZCBhZGQgdG9vIG11Y2gg
b3ZlcmhlYWQuPC9wPjxwPlNob3VsZCB3ZSBoYXZlIGFuIGV4dHJhIG1ldGhvZCBpbiBTZWdtZW50
QWxsb2NhdG9yIHdoaWNoIHN0YXRlcyB3aGF0J3MgdGhlIHplcm9pbmcgcG9saWN5IGZvciB0aGUg
YWxsb2NhdG9yPzwvcD48cD5JdCdzIGNlcnRhaW5seSBjaGVhcCB0byBhZGQsIGJ1dDo8L3A+PHA+
KiB1c2VycyB3aWxsIGZvcmdldCB0byBvdmVycmlkZSB0aGF0IChlc3AuIGdpdmVuIFNlZ21lbnRB
bGxvY2F0b3IgaXMgYSBmdW5jdGlvbmFsIGludGVyZmFjZSk8YnI+KiBpdCBvbmx5IGFkZHJlc3Nl
cyBfb25lXyBkaW1lbnNpb24gaW4gd2hpY2ggYSBnaXZlbiBhbGxvY2F0b3IgaXMgc3BlY2lhbCAt
IGFyZSB0aGVyZSBvdGhlcnM/IChlLmcuIGRpc2pvaW50bmVzcyBvZiByZXR1cm5lZCBzZWdtZW50
cywgZXRjKTxicj4qIGFub3RoZXIgYXBwcm9hY2ggY291bGQgYmUgZm9yIGNsaWVudHMgdGhhdCBk
byB3YW50IGd1YXJhbnRlZWQgemVyb2luZyB0byBhbHdheXMgY2FsbCBNUzo6ZmlsbCwgYW5kIHJl
bHkgb24gQzIgdG8gZWxpbWluYXRlIHRoZSByZWR1bmRhbnQgbWVtc2V0IChhZnRlciBhbGwgVW5z
YWZlOjpzZXRNZW1vcnkgaXMgYW4gaW50cmluc2ljcykuIFRoaXMgaXMgaGFyZCB0byBhY2hpZXZl
LCBidXQgd291bGQgcHJvYmFibHkgbGVhZCB0byBhIGJldHRlciBsb25nLXRlcm0gcGF0aCwgd2hl
cmUgd2UgY2FuIHN0b3Agd29ycnlpbmcgYWJvdXQgZHVwbGljYXRlIHplcm9pbmcgKGFzIGhhcHBl
bnMgZm9yIG9uLWhlYXAgYXJyYXlzKS4gQXQgdGhpcyBwb2ludCBoYXZpbmcgdGhlIHByZWRpY2F0
ZSBvbiBgU2VnbWVudEFsbG9jYXRvcmAgd291ZG4ndCBhZGQgdG9vIG11Y2guPC9wPjxwPkZvciBh
bGwgdGhlc2UgcmVhc29ucywgSSdtIHNsaWdodGx5IGFnYWluc3QgYWRkaW5nIG5ldyBtZXRob2Rz
IHRvIFNlZ21lbnRBbGxvY2F0b3IuIE9mIGNvdXJzZSBpZiB0aGlzIHJlcXVlc3RzIHR1cm5lZCBv
dXQgdG8gYmUgYSB2ZXJ5IGNvbW1vbiBvbmUgSSBjb3VsZCByZWNvbnNpZGVyIG9mIGNvdXJzZS48
L3A+PHA+TGFzdCwgbm90ZSB0aGF0IHRoZXJlJ3MgYSB3b3JrYXJvdW5kLCBldmVuIHRob3VnaCBp
dCBtaWdodCBub3QgbG9vayB0b28gcHJldHR5LiBMZXQncyBzYXkgdGhhdCB5b3Uga25vdyB0aGF0
IHlvdSBvbmx5IGFsbG9jYXRlIDEwMjQgYnl0ZXMgdG9wcy4gVGhlbiB5b3UgY2FuIGRvIGxpa2Ug
c286PC9wPjxwPmBgYGphdmE8YnI+TWVtb3J5U2VnbWVudCBhbGxvY2F0ZUFuZFplcm8oU2VnbWVu
dEFsbG9jYXRvciBhbGxvY2F0b3IsIGxvbmcgc2l6ZSkgezxicj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgY2xhc3MgSG9sZGVyIHs8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0YXRpYyBNZW1vcnlTZWdtZW50IFpF
Uk8gPSBNZW1vcnlTZWdtZW50Lm9mQXJyYXkobmV3IGJ5dGVbMTAyNF0pOzxicj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgfTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLy8gdG9kbzogY2hl
Y2sgdGhhdCBgc2l6ZSAmbHQ7IDEwMjRgPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByZXR1
cm4gYWxsb2NhdG9yLmFsbG9jYXRlRnJvbShKQVZBX0JZVEUsIEhvbGRlci5aRVJPLCBKQVZBX0JZ
VEUsIDAsIHNpemUpOzxicj59PGJyPmBgYDwvcD48cD5Ob3RlIHRoYXQgdGhpcyB1c2VzIGBhbGxv
Y2F0ZUZyb21gIHRvIGFsbG9jYXRlIGEgbWVtb3J5IHNlZ21lbnQgb2YgZ2l2ZW4gc2l6ZSwgYW5k
IHRoZW4gYnVsayBjb3B5IChhIHBhcnQgb2YpIHRoZSAiemVybyBzZWdtZW50IiBvbiB0b3Agb2Yg
aXQuIFRoaXMgd29uJ3QgcGVyZm9ybSBkb3VibGUgemVyb2luZywgYmVjYXVzZSBgU2VnbWVudEFs
bG9jYXRvcjo6YWxsb2NhdGVGcm9tYCB0cmllcyB0byBhdm9pZCB0aGF0IGFsc28uIFRoZSBvbmx5
IGRpZmZlcmVuY2UgaXMgdGhhdCB3ZSdyZSB1c2luZyAiVW5zYWZlOjpjb3B5TWVtb3J5IiBpbnN0
ZWFkIG9mICJVbnNhZmU6OnNldE1lbW9yeSIgdG8gemVybyB0aGUgbWVtb3J5IChidXQgYm90aCBz
aG91bGQgcGVyZm9ybSByb3VnaGx5IHRoZSBzYW1lLCBhcyB0aGV5IGFyZSBib3RoIGludHJpbnNp
Y3MgdGhhdCBzdXBwb3J0IHZlY3Rvcml6ZWQgaW5zdHJ1Y3Rpb25zKS4gSXQncyBub3QgcHJldHR5
LCBidXQgbWF5YmUgY291bGQgYmUgb2sgd2hpbGUgd2Ugd2FpdCBmb3IgZGVlcGVyICJkdXBsaWNh
dGUgemVybyBtZW1zZXQiIGF2b2lkYW5jZT88YnI+PC9wPjxwPk1hdXJpemlvPGJyPjwvcD48cD48
YnI+PC9wPg==" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0;"></div>
</div>
</body>
</html>