As part of feedback on the Foreign Memory API (when experimenting with
This change proposes to add a new method:
Which fills a value into the given memory segment. Fill can be useful to
There are obviously different ways to provide such functionality, e.g.
@ChrisHegarty This change now passes all automated pre-integration checks, type
Since the source branch of this PR was last updated there has been 1 commit pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid automatic rebasing, please merge
As you do not have Committer status in this project, an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@JimLaskey, @JornVernee, @PaulSandoz, @mcimadamore) but any other Committer may sponsor as well.
PaulSandoz left a comment
Nice and simple, but i think there is an open design question here.
Notice that the bulk
I think we need to consider grouping bulk operations in the same place.
I suggested the location to Chris. Since the method operates on segment it felt right to add it on MemorySegment. If we add it on MemoryAddress it will look a tad odd IMHO, since it works on segments.
We could tweak fill to work on MemoryAddress, but that means that the user has to pass an address and a length (which is what a segment is).
Or we could make fill an instance method on segment.
I'm not sure there's one answer that's better than the others here - but I don't have any strong feelings one way or another, so I'm open to suggestions.
As separate issues perhaps consider moving or duplicating
On May 13, 2020, at 9:40 AM, Chris Hegarty <chegar at openjdk.java.net> wrote:
We have an odd legacy from Java arrays that we are working with.
For Java arrays, some other designs would seem to be better,
1. Add a static overloaded method Array::copy which provides
2. Add virtual methods to each array type which turn the receiver into
3. Have a span type which reies a slice of such an array. Add the
I list these out because the MemorySegment work could use these
So, native array : MemorySegment :: System.arraycopy : (what?)
(I suppose this game can be played with other ju.Arrays methods.)
Thought a bit more about this.
There's an additional angle to the problem of segment vs. address which we didn't discuss. While all segments have a base address, the reverse is not true: if an address is unchecked (e.g. created from
Because of this, one could argue that the signature of the
A way out would be again, to express
This is all and well; now we can only pass segments to the routine, which rules out the unchecked address issue. But still feels a bit redundant - after all, we can easily express offsets in terms of segment slices (which was pointed out by Paul at some point). So we can actually do this:
This is nice, but I think that once we view this method as operating on segments, I think it makes sense to turn them into proper instance methods, and just do:
Can we do the same with
Very simple (instance) method.
And, looking a bit ahead, we will want to have a functionality equivalent to
So my recommendation would be for:
This should lead to a more self-consistent, and discoverable API. Thoughts?
@mcimadamore I really like this suggestion (instance methods on MemorySegment). Especially given unchecked memory addresses, your proposal to move
This design assumes slices are relatively cheap, given that more slicing will be needed to interact with API points, but that should probably be ok.
For arrays we never really had any choice (static vs. instance), although i still hold out hope someday we can make arrays implement a richer array'ish interface.
As you might guess from my leading comments, I very much like the idea of
The problem with static methods is all the arguments "look alike", and so
If a MS has a utility method for sending data somewhere else, it shouldn't
On 14/05/2020 21:50, John R Rose wrote:
Agree - in my comment I think I specifically used `copyTo` and the
I'm not too worried that other methods don't have suffixes, since they