BUG: withOwnerThread closes MappedMemorySegment

[Ty Young]

Javadoc isn't working for withOwnerThread or withCleanupAction for me on 
Netbeans:


https://imgur.com/a/Q21pZAC


Says it's downloading HTTP Javadoc for about 10 seconds then gives up. 
Javadoc of other older methods work just fine and I didn't think it'd 
close the segment as other withers(withAccessModes) do not.


So I wasn't able to read it, my bad.


Question: is this an absolute requirement because of technical 
restrains? Could this be removed so that, for example, it is possible to 
make an array segment unbound but have individual array index segments 
be bound to a specific thread?


On 9/23/20 12:00 AM, sundararajan.athijegannathan at oracle.com wrote:
> javadoc of MemorySegment.withOwnerThread starts as follows:
>
> "    * Obtains a new memory segment backed by the same underlying 
> memory region as this segment,
>      * but with different owner thread. As a side-effect, this segment 
> will be marked as <em>not alive</em>,
>      * and subsequent operations on this segment will result in 
> runtime errors.
> "
>
> So the behavior seen is as the specification.
>
> -Sundar
>
> On 23/09/20 7:36 am, Ty Young wrote:
>> A bug seems to have been introduced wherein using withOwnerThread 
>> causes a MappedMemorySegment to close:
>>
>>
>>     File file = new File("./test");
>>
>>         if(file.exists())
>>             file.delete();
>>
>>         file.createNewFile();
>>
>>         MappedMemorySegment nativeFile = 
>> MemorySegment.mapFromPath(file.toPath(), 0, 4096, 
>> FileChannel.MapMode.READ_WRITE);
>>
>>         System.out.println(nativeFile.isAlive());
>>
>>         MappedMemorySegment segment = 
>> (MappedMemorySegment)nativeFile.asSlice(4);
>>         segment = (MappedMemorySegment)nativeFile.asSlice(4);
>>         segment = 
>> (MappedMemorySegment)nativeFile.asSlice(4).withOwnerThread(null);
>>
>>         System.out.println(nativeFile.isAlive());
>>         System.out.println(segment.isAlive());
>>
>>
>> which prints true, false, and then true. The original 
>> MappedMemorySegment was never closed, so this is unexpected.
>>