On Dec 1, 2019, at 8:07 AM, David Lloyd wrote:
>
> Okay, anyway I'm glad that I'm not the first person to have thought of
> these use cases. The API looks good!
Thanks for reviewing and commenting! We need to “shake out” our
designs exactly like that.
— John
On Fri, Nov 29, 2019 at 5:34 PM John Rose wrote:
>
> On Nov 29, 2019, at 4:24 AM, David Lloyd wrote:
>
>
> Makes sense, it's still early. But now the seed is planted. :)
>
>
> (It’s better documented. Most of the points made here were not new.)
Okay, anyway I'm glad that I'm not the first pers
On Nov 29, 2019, at 4:24 AM, David Lloyd wrote:
>
> Makes sense, it's still early. But now the seed is planted. :)
(It’s better documented. Most of the points made here were not new.)
On 29/11/2019 19:32, Florian Weimer wrote:
* Maurizio Cimadamore:
While this could be done (and it was considered early during the design
phase), we decided against it for two reasons: first, the VarHandle API
is very expressive and already supports. atomic compareAndSwap
operations out of th
* Maurizio Cimadamore:
> While this could be done (and it was considered early during the design
> phase), we decided against it for two reasons: first, the VarHandle API
> is very expressive and already supports. atomic compareAndSwap
> operations out of the box, which are _very_ handy when d
On Thu, Nov 28, 2019 at 11:24 AM Vladimir Ivanov
wrote:
>
>
> >> Second, what about an API to allocate memory from the stack? This is
> >> really useful in GraalVM (granted they have a sort-of-Panama-ish way
> >> of calling C functions already, and they're really quite "loose" when
> >> it comes
Second, what about an API to allocate memory from the stack? This is
really useful in GraalVM (granted they have a sort-of-Panama-ish way
of calling C functions already, and they're really quite "loose" when
it comes to safety in some regards) and could simplify some things
already, particular
Hi David
On 27/11/2019 14:04, David Lloyd wrote:
On Mon, Nov 25, 2019 at 11:28 AM wrote:
https://openjdk.java.net/jeps/370
One more question! Well, two I guess.
First, in the interim before Panama or something like it comes to the
main project, will it be possible to pass MemoryAddress kind
On Mon, Nov 25, 2019 at 11:28 AM wrote:
>
> https://openjdk.java.net/jeps/370
One more question! Well, two I guess.
First, in the interim before Panama or something like it comes to the
main project, will it be possible to pass MemoryAddress kinds of
things to JNI methods (to replace the curren
Very good suggestion - thanks; I will fix it.
Cheers
Maurizio
On 26/11/2019 20:32, Johannes Kuhn wrote:
Hi,
Just had the chance to look at the proposal, and I have a small suggestion:
MemorySegmenent::mapFromPath should state that it can throw a SecurityException
if a SecurityManager is insta
Hi,
Just had the chance to look at the proposal, and I have a small suggestion:
MemorySegmenent::mapFromPath should state that it can throw a SecurityException
if a SecurityManager is installed in the javadoc.
The description can be copied from FileChannel::open.
With best regards,
Johannes
On 25/11/2019 20:04, David Lloyd wrote:
On Mon, Nov 25, 2019 at 11:28 AM wrote:
https://openjdk.java.net/jeps/370
Looks pretty interesting! Why make the API user deal with VarHandles
though, as opposed to (say) putting accessor methods directly onto
MemoryAddress?
While this could be done
On Mon, Nov 25, 2019 at 11:28 AM wrote:
>
> https://openjdk.java.net/jeps/370
Looks pretty interesting! Why make the API user deal with VarHandles
though, as opposed to (say) putting accessor methods directly onto
MemoryAddress?
--
- DML
https://openjdk.java.net/jeps/370
- Mark
14 matches
Mail list logo
