RFR(M): 8171181: Supporting heap allocation on alternative memory devices

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
Hello all!
I have proposed a JEP to support allocation of Java heap on new memory devices such as NV-DIMMs like Intel's 3D XPoint.
Such a feature has applications in multi-JVM deployments, big data applications and in-memory databases.
Please find the details here - https://bugs.openjdk.java.net/browse/JDK-8171181 and the patch for the implementation is at http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04
I would appreciate a review and feedback from the community for this JEP.
Thank you!
Kishor

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

David Holmes
Hi Kishor,

I took a quick look at this and have a few initial comments ... but
overall it looks pretty straight-forward.

On 28/02/2017 9:52 AM, Kharbas, Kishor wrote:
> Hello all!
> I have proposed a JEP to support allocation of Java heap on new memory devices such as NV-DIMMs like Intel's 3D XPoint.
> Such a feature has applications in multi-JVM deployments, big data applications and in-memory databases.
> Please find the details here - https://bugs.openjdk.java.net/browse/JDK-8171181 and the patch for the implementation is at http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04
> I would appreciate a review and feedback from the community for this JEP.

Is there something linux specific about the implementation? If not it
should be in os_posix.cpp and be usable by all the POSIX compliant OS.

In os::create_file_for_heap:

  - you need to use the per-thread signal masking function,
pthread_sigmask, not sigprocmask. Also you need restore the signal mask
before the error return of -1
  - you can't use umask as that might impact files concurrently created
by other code in the VM. I expect you will need to create it then fchmod it.
  - the warning should include the reason for the failure. Though it is
unclear whether this should be a warning or a fatal error.
  - check returns codes from library calls - add assertions that they
succeed if they should be "impossible" to fail. Though I think perhaps
an unlink failure may need to be anticipated.

In os::map_memory_to_file:
  - report reasons for failure explicitly
  - do not assign posix_fallocate to errno!

The err_msg function is used for printf-style formatting, so you don't
need it for simple string messages. But in some cases your messages
should also include strerror output when there are failures.

Some tests will also be needed of course.

Thanks,
David

> Thank you!
> Kishor
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Thomas Stüfe-2
In reply to this post by Kharbas, Kishor
Hi Kishor,

This looks interesting. We are responsible for some of the more exotic
ports, e.g. AIX, so we have an interest in making a simple and generic
solution for potential future different implementations.

So here some more suggestions (apart from what David already wrote):

-----

I see that the mapping to file is implemented in a way that it always
follows the anonymous mapping. I dislike about the implementation that we
now carry the file-desc argument down through the memory apis and that
these APIs are overloaded with yet another implementation detail. Also, it
makes the implementation rigid, only applicable for this one issue
(allocating non-large-paged java heap).

I suggest a different approach. Keep your map_file_to_memory() function,
but instead calling it deep in the belly of os::reserve_memory() and
friends, you could add it as a new "first class" api to os.hpp, something
like "os::replace_existing_mapping_with_file_mapping(addr, size,
filedesc)". That function would attempt to replace the given existing
mapping at [addr,size] with the given file mapping, same as your
map_file_to_memory does now.
Difference would be that this function can be called anytime after
os::reserve_memory() returns, in case of the jave heap in virtualspace.cpp.
You would not have to modify the os::reserve_memory() functions and not add
another parameter to them.

The process of replacing the anon mapping with the file mapping would be
separated from the process of java heap allocation. This approach would be
more flexible:

It could be also used for memory reserved in different ways, e.g. for large
paged pinned memory. Maybe it would not work in your case, but this leaves
more room for future different implementations. In fact, in this case the
coding in virtualspace.cpp would be easier, you would not have to
distinguish between special (large paged pinned) reservations and normal
reservations, just let ReservedSpace reserve its memory range and at the
end of ReservedSpace::initialize(), when all the reservation magic is done
and the reserved memory range exists - where ever and in whatever form it
was allocated - then attempt to replace this with your mapping by calling
your "os::replace_existing_mapping_with_file_mapping()".

It may work or not - you may be able to replace whatever memory
ReservedSpace did allocate with whatever special memory you are introducing
with the file descriptor. For your case, attempting to replace large paged
pinned memory with your NVDIMMS, you would probably get an error and could
output a clear message to the user that UseLargePages and AllocateHeapAt
are mutually exclusive. Or, the large paged memory would be silently
replaced with small paged memory, in which case one has the choice of
either continuing or stopping with an error message.

In fact, this API could also be used for different things than the jave
heap, e.g. metaspace or code heap. Or maybe even thread stacks, who knows.

-----------

Apart from these general remarks, here some code review (all remarks refer
to os_linux.cpp):

+  const char name_template[] = "/jvmheap.XXXXXX";
+  char *fullname = (char*)alloca(strlen(dir) + sizeof(name_template));
+  (void)strcpy(fullname, dir);
+  (void)strcat(fullname, name_template);

I think the array is 1 byte too short, you need to allocate space for the
trailing zero. Same error in os_windows.cpp.

-----

+  // block all signals while we do the file operation.
+  (void)sigprocmask(SIG_BLOCK, &set, &oldset);

This is quite dangerous. You switch off signal handling for the whole
process. Any non-delay-able error signal will immediately kill the process
without trace. What if another thread has an implicit null check?

I also do not understand why this is needed?

-----

+  // set the file creation mask.
+  mode_t new_mask = S_IRUSR | S_IWUSR;
+  mode_t prev_umask = umask(new_mask);
+
+  // create a new file.
+  int fd = mkstemp(fullname);

What David said, this is for the whole process and therefore may clash with
other threads.

David suggested fchmod, but I wonder is it even necessary to set the umask
in this case?

http://man7.org/linux/man-pages/man3/mkstemp.3.html

       The file is created with permissions 0600, that is, read plus write
       for owner only.  The returned file descriptor provides both read and
       write access to the file.  The file is opened with the open(2) O_EXCL
       flag, guaranteeing that the caller is the process that creates the
       file.

Would the default value not be what you want?

----

At various places you fail if system calls fail. E.g.

+ warning("Failure to create file %s for heap", fullname);

Could you print out the errno for those cases, or strerror() ?

----

Kind regards, Thomas



On Tue, Feb 28, 2017 at 12:52 AM, Kharbas, Kishor <[hidden email]>
wrote:

> Hello all!
> I have proposed a JEP to support allocation of Java heap on new memory
> devices such as NV-DIMMs like Intel's 3D XPoint.
> Such a feature has applications in multi-JVM deployments, big data
> applications and in-memory databases.
> Please find the details here - https://bugs.openjdk.java.net/
> browse/JDK-8171181 and the patch for the implementation is at
> http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04
> I would appreciate a review and feedback from the community for this JEP.
> Thank you!
> Kishor
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Andrew Haley
In reply to this post by Kharbas, Kishor
Is it -XX:HeapDir or -XX:AllocateHeapAt ?  JEP says AllocateHeapAt, impl
does not.

+             "Limit on number of compiler directives.")                     \
+                                                                            \
+  product(ccstr, HeapDir, NULL,                                             \
+          "Path to the directoy where a temporary file will be created      \
+           to use as the backing store for Java Heap.")


Spell "directory"

Do we ever envisage splitting the heap over memory types?

Is it essential to disable NUMA when using alternative memory devices?

Andrew.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
In reply to this post by David Holmes
Hi David!
Thanks a lot for the review, I will work on your comments and from others. Will provide an update soon!

I only have a few clarifications -

1. On you comment
        > In os::create_file_for_heap:
        >   - the warning should include the reason for the failure. Though it is unclear
        > whether this should be a warning or a fatal error.
    My thinking was to let the calling function in VirtualSpace.cpp handle the correct action. And it does terminate the application.

2. > In os::map_memory_to_file:
     >   - report reasons for failure explicitly

     Do you mean the message in "vm_exit_during_initialization(err_msg("Error in mapping Java heap at the given filesystem directory"));" should be more explicit?

Thanks
Kishor

> -----Original Message-----
> From: David Holmes [mailto:[hidden email]]
> Sent: Monday, February 27, 2017 5:41 PM
> To: Kharbas, Kishor <[hidden email]>; hotspot-runtime-
> [hidden email]
> Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative
> memory devices
>
> Hi Kishor,
>
> I took a quick look at this and have a few initial comments ... but overall it
> looks pretty straight-forward.
>
> On 28/02/2017 9:52 AM, Kharbas, Kishor wrote:
> > Hello all!
> > I have proposed a JEP to support allocation of Java heap on new memory
> devices such as NV-DIMMs like Intel's 3D XPoint.
> > Such a feature has applications in multi-JVM deployments, big data
> applications and in-memory databases.
> > Please find the details here -
> > https://bugs.openjdk.java.net/browse/JDK-8171181 and the patch for the
> > implementation is at
> > http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04
> > I would appreciate a review and feedback from the community for this JEP.
>
> Is there something linux specific about the implementation? If not it should
> be in os_posix.cpp and be usable by all the POSIX compliant OS.
>
> In os::create_file_for_heap:
>
>   - you need to use the per-thread signal masking function, pthread_sigmask,
> not sigprocmask. Also you need restore the signal mask before the error
> return of -1
>   - you can't use umask as that might impact files concurrently created by
> other code in the VM. I expect you will need to create it then fchmod it.
>   - the warning should include the reason for the failure. Though it is unclear
> whether this should be a warning or a fatal error.
>   - check returns codes from library calls - add assertions that they succeed if
> they should be "impossible" to fail. Though I think perhaps an unlink failure
> may need to be anticipated.
>
> In os::map_memory_to_file:
>   - report reasons for failure explicitly
>   - do not assign posix_fallocate to errno!
>
> The err_msg function is used for printf-style formatting, so you don't need it
> for simple string messages. But in some cases your messages should also
> include strerror output when there are failures.
>
> Some tests will also be needed of course.
>
> Thanks,
> David
>
> > Thank you!
> > Kishor
> >
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

David Holmes
On 1/03/2017 12:49 PM, Kharbas, Kishor wrote:

> Hi David!
> Thanks a lot for the review, I will work on your comments and from others. Will provide an update soon!
>
> I only have a few clarifications -
>
> 1. On you comment
> > In os::create_file_for_heap:
> >   - the warning should include the reason for the failure. Though it is unclear
> > whether this should be a warning or a fatal error.
>     My thinking was to let the calling function in VirtualSpace.cpp handle the correct action. And it does terminate the application.

Okay - then you don't need the warning as well. The caller should give a
detailed error message.

> 2. > In os::map_memory_to_file:
>      >   - report reasons for failure explicitly
>
>      Do you mean the message in "vm_exit_during_initialization(err_msg("Error in mapping Java heap at the given filesystem directory"));" should be more explicit?

I mean including the actual error reason, strerror(errno) for example,
in the error messages.

Thanks,
David
-----

> Thanks
> Kishor
>
>> -----Original Message-----
>> From: David Holmes [mailto:[hidden email]]
>> Sent: Monday, February 27, 2017 5:41 PM
>> To: Kharbas, Kishor <[hidden email]>; hotspot-runtime-
>> [hidden email]
>> Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative
>> memory devices
>>
>> Hi Kishor,
>>
>> I took a quick look at this and have a few initial comments ... but overall it
>> looks pretty straight-forward.
>>
>> On 28/02/2017 9:52 AM, Kharbas, Kishor wrote:
>>> Hello all!
>>> I have proposed a JEP to support allocation of Java heap on new memory
>> devices such as NV-DIMMs like Intel's 3D XPoint.
>>> Such a feature has applications in multi-JVM deployments, big data
>> applications and in-memory databases.
>>> Please find the details here -
>>> https://bugs.openjdk.java.net/browse/JDK-8171181 and the patch for the
>>> implementation is at
>>> http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04
>>> I would appreciate a review and feedback from the community for this JEP.
>>
>> Is there something linux specific about the implementation? If not it should
>> be in os_posix.cpp and be usable by all the POSIX compliant OS.
>>
>> In os::create_file_for_heap:
>>
>>   - you need to use the per-thread signal masking function, pthread_sigmask,
>> not sigprocmask. Also you need restore the signal mask before the error
>> return of -1
>>   - you can't use umask as that might impact files concurrently created by
>> other code in the VM. I expect you will need to create it then fchmod it.
>>   - the warning should include the reason for the failure. Though it is unclear
>> whether this should be a warning or a fatal error.
>>   - check returns codes from library calls - add assertions that they succeed if
>> they should be "impossible" to fail. Though I think perhaps an unlink failure
>> may need to be anticipated.
>>
>> In os::map_memory_to_file:
>>   - report reasons for failure explicitly
>>   - do not assign posix_fallocate to errno!
>>
>> The err_msg function is used for printf-style formatting, so you don't need it
>> for simple string messages. But in some cases your messages should also
>> include strerror output when there are failures.
>>
>> Some tests will also be needed of course.
>>
>> Thanks,
>> David
>>
>>> Thank you!
>>> Kishor
>>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
In reply to this post by Thomas Stüfe-2
Thanks Thomas for providing a different perspective. It will definitely make the implementation simpler and flexible.
I will work on this approach; hopefully there aren’t unforeseen hurdles.

I agree with the other comment, I should fix that.
I have explicitly set a mask as a precaution, since older implementations set permission to 0666.

Thanks
Kishor

From: Thomas Stüfe [mailto:[hidden email]]
Sent: Tuesday, February 28, 2017 1:18 AM
To: Kharbas, Kishor <[hidden email]>; David Holmes <[hidden email]>
Cc: [hidden email]
Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Hi Kishor,

This looks interesting. We are responsible for some of the more exotic ports, e.g. AIX, so we have an interest in making a simple and generic solution for potential future different implementations.

So here some more suggestions (apart from what David already wrote):

-----

I see that the mapping to file is implemented in a way that it always follows the anonymous mapping. I dislike about the implementation that we now carry the file-desc argument down through the memory apis and that these APIs are overloaded with yet another implementation detail. Also, it makes the implementation rigid, only applicable for this one issue (allocating non-large-paged java heap).

I suggest a different approach. Keep your map_file_to_memory() function, but instead calling it deep in the belly of os::reserve_memory() and friends, you could add it as a new "first class" api to os.hpp, something like "os::replace_existing_mapping_with_file_mapping(addr, size, filedesc)". That function would attempt to replace the given existing mapping at [addr,size] with the given file mapping, same as your map_file_to_memory does now.
Difference would be that this function can be called anytime after os::reserve_memory() returns, in case of the jave heap in virtualspace.cpp. You would not have to modify the os::reserve_memory() functions and not add another parameter to them.

The process of replacing the anon mapping with the file mapping would be separated from the process of java heap allocation. This approach would be more flexible:

It could be also used for memory reserved in different ways, e.g. for large paged pinned memory. Maybe it would not work in your case, but this leaves more room for future different implementations. In fact, in this case the coding in virtualspace.cpp would be easier, you would not have to distinguish between special (large paged pinned) reservations and normal reservations, just let ReservedSpace reserve its memory range and at the end of ReservedSpace::initialize(), when all the reservation magic is done and the reserved memory range exists - where ever and in whatever form it was allocated - then attempt to replace this with your mapping by calling your "os::replace_existing_mapping_with_file_mapping()".

It may work or not - you may be able to replace whatever memory ReservedSpace did allocate with whatever special memory you are introducing with the file descriptor. For your case, attempting to replace large paged pinned memory with your NVDIMMS, you would probably get an error and could output a clear message to the user that UseLargePages and AllocateHeapAt are mutually exclusive. Or, the large paged memory would be silently replaced with small paged memory, in which case one has the choice of either continuing or stopping with an error message.

In fact, this API could also be used for different things than the jave heap, e.g. metaspace or code heap. Or maybe even thread stacks, who knows.

-----------

Apart from these general remarks, here some code review (all remarks refer to os_linux.cpp):

+  const char name_template[] = "/jvmheap.XXXXXX";
+  char *fullname = (char*)alloca(strlen(dir) + sizeof(name_template));
+  (void)strcpy(fullname, dir);
+  (void)strcat(fullname, name_template);

I think the array is 1 byte too short, you need to allocate space for the trailing zero. Same error in os_windows.cpp.

-----

+  // block all signals while we do the file operation.
+  (void)sigprocmask(SIG_BLOCK, &set, &oldset);

This is quite dangerous. You switch off signal handling for the whole process. Any non-delay-able error signal will immediately kill the process without trace. What if another thread has an implicit null check?

I also do not understand why this is needed?

-----

+  // set the file creation mask.
+  mode_t new_mask = S_IRUSR | S_IWUSR;
+  mode_t prev_umask = umask(new_mask);
+
+  // create a new file.
+  int fd = mkstemp(fullname);

What David said, this is for the whole process and therefore may clash with other threads.

David suggested fchmod, but I wonder is it even necessary to set the umask in this case?

http://man7.org/linux/man-pages/man3/mkstemp.3.html

       The file is created with permissions 0600, that is, read plus write
       for owner only.  The returned file descriptor provides both read and
       write access to the file.  The file is opened with the open(2) O_EXCL
       flag, guaranteeing that the caller is the process that creates the
       file.

Would the default value not be what you want?

----

At various places you fail if system calls fail. E.g.

+ warning("Failure to create file %s for heap", fullname);

Could you print out the errno for those cases, or strerror() ?

----

Kind regards, Thomas



On Tue, Feb 28, 2017 at 12:52 AM, Kharbas, Kishor <[hidden email]<mailto:[hidden email]>> wrote:
Hello all!
I have proposed a JEP to support allocation of Java heap on new memory devices such as NV-DIMMs like Intel's 3D XPoint.
Such a feature has applications in multi-JVM deployments, big data applications and in-memory databases.
Please find the details here - https://bugs.openjdk.java.net/browse/JDK-8171181 and the patch for the implementation is at http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04
I would appreciate a review and feedback from the community for this JEP.
Thank you!
Kishor

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
In reply to this post by Andrew Haley
Hi Andrew,

> -----Original Message-----
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> [hidden email]] On Behalf Of Andrew Haley
> Sent: Tuesday, February 28, 2017 1:33 AM
> To: [hidden email]
> Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative
> memory devices
>
> Is it -XX:HeapDir or -XX:AllocateHeapAt ?  JEP says AllocateHeapAt, impl does
> not.
>
> +             "Limit on number of compiler directives.")                     \
> +                                                                            \
> +  product(ccstr, HeapDir, NULL,                                             \
> +          "Path to the directoy where a temporary file will be created      \
> +           to use as the backing store for Java Heap.")
>
>
> Spell "directory"
>

My thinking was to wait until the flag name is finalized in the JEP. I myself am not completely happy with the name so I was thinking if the community comes up with a better one.


> Do we ever envisage splitting the heap over memory types?
>

Yes there could be a java heap split over memory types and object can be allocated in respective memories using automatic (using profiling) placement or user directed by APIs and/or language extensions.

> Is it essential to disable NUMA when using alternative memory devices?
>

From the research I have done, the DAX filesystem do not support NUMA-aware placement.

> Andrew.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Andrew Haley
On 01/03/17 03:26, Kharbas, Kishor wrote:

>> Is it essential to disable NUMA when using alternative memory devices?
>
> From the research I have done, the DAX filesystem do not support NUMA-aware placement.

So what?  This change isn't DAX-specific, is it?

Andrew.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
Hi Andrew!

The JEP is not DAX specific, but the implementation is.
Do you have any ideas on how we can check whether NUMA is supported by the underlying filesystem?

Thanks
Kishor

> -----Original Message-----
> From: Andrew Haley [mailto:[hidden email]]
> Sent: Wednesday, March 1, 2017 1:50 AM
> To: Kharbas, Kishor <[hidden email]>; hotspot-runtime-
> [hidden email]
> Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative
> memory devices
>
> On 01/03/17 03:26, Kharbas, Kishor wrote:
>
> >> Is it essential to disable NUMA when using alternative memory devices?
> >
> > From the research I have done, the DAX filesystem do not support NUMA-
> aware placement.
>
> So what?  This change isn't DAX-specific, is it?
>
> Andrew.
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Andrew Haley
On 03/03/17 03:32, Kharbas, Kishor wrote:

> The JEP is not DAX specific, but the implementation is.
> Do you have any ideas on how we can check whether NUMA is supported
> by the underlying filesystem?

What are the consequences if it isn't?  All that this patch does (as
far as I can see) is allow the heap to be allocated in a file in a
named directory.  So, will there be failures if the system does
support NUMA but the DAX filesystem doesn't?

Andrew.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Jini Susan George
In reply to this post by Kharbas, Kishor
Hi Kishor,

Wanted a clarification. For Linux, wouldn't the coredump_filter file
also have to be modified (by setting bit 3 or bit 8 ?) to ensure that
the java heap gets dumped into the corefile when a coredump occurs ?

Thanks,
Jini.

On 2/28/2017 5:22 AM, Kharbas, Kishor wrote:
> Hello all!I have proposed a JEP to support allocation of Java heap on
> new memory devices such as NV-DIMMs like Intel's 3D XPoint. Such a
> feature has applications in multi-JVM deployments, big data
> applications and in-memory databases. Please find the details here -
> https://bugs.openjdk.java.net/browse/JDK-8171181 and the patch for the
> implementation is at
> http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04 I would
> appreciate a review and feedback from the community for this JEP.
> Thank you! Kishor

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
In reply to this post by Andrew Haley
Hi Andrew!

> -----Original Message-----
> From: Andrew Haley [mailto:[hidden email]]
> Sent: Friday, March 3, 2017 1:21 AM
> To: Kharbas, Kishor <[hidden email]>; hotspot-runtime-
> [hidden email]
> Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative
> memory devices
>
> On 03/03/17 03:32, Kharbas, Kishor wrote:
>
> > The JEP is not DAX specific, but the implementation is.
> > Do you have any ideas on how we can check whether NUMA is supported
> by
> > the underlying filesystem?
>
> What are the consequences if it isn't?  All that this patch does (as far as I can
> see) is allow the heap to be allocated in a file in a named directory.

Yes that's right, it just allocates heap in a file in the given directory. My understanding is that this flag will be used by advanced Java users who would understand that they need to specify a DAX or a special directory to access the new memory.

 So, will
> there be failures if the system does support NUMA but the DAX filesystem
> doesn't?

I don't think there will be failures if that happens. The user needs to be let known that NUMA is not supported if he tries to use NUMA in conjunction to this flag.

>
> Andrew.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
In reply to this post by Jini Susan George
Hi Jini!

Yes that's right, the coredump_filter needs to modified to dump file-backed shared mappings.

Thanks for pointing this out!

Kishor

> -----Original Message-----
> From: Jini George [mailto:[hidden email]]
> Sent: Saturday, March 4, 2017 1:01 AM
> To: Kharbas, Kishor <[hidden email]>; hotspot-runtime-
> [hidden email]
> Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative
> memory devices
>
> Hi Kishor,
>
> Wanted a clarification. For Linux, wouldn't the coredump_filter file also have
> to be modified (by setting bit 3 or bit 8 ?) to ensure that the java heap gets
> dumped into the corefile when a coredump occurs ?
>
> Thanks,
> Jini.
>
> On 2/28/2017 5:22 AM, Kharbas, Kishor wrote:
> > Hello all!I have proposed a JEP to support allocation of Java heap on
> > new memory devices such as NV-DIMMs like Intel's 3D XPoint. Such a
> > feature has applications in multi-JVM deployments, big data
> > applications and in-memory databases. Please find the details here -
> > https://bugs.openjdk.java.net/browse/JDK-8171181 and the patch for the
> > implementation is at
> > http://cr.openjdk.java.net/~kkharbas/8153327_webrev.04 I would
> > appreciate a review and feedback from the community for this JEP.
> > Thank you! Kishor

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Andrew Haley
In reply to this post by Kharbas, Kishor
On 06/03/17 21:19, Kharbas, Kishor wrote:
> I don't think there will be failures if that happens. The user needs to be let known that NUMA is not supported if he tries to use NUMA in conjunction to this flag.

I'm wondering if perhaps I'm not speaking clearly.  Please, let me spell
out my thinking:

a.  This flag can be used by the DAX filesystem, but can be used by any
filesystem.

b.  For example, it might be used to put the heap onto a file in, say,
a RAM-backed file where NUMA is supported.

c.  On such a system, NUMA might be available and useful.

d.  Therefore it is not appropriate to tell people that NUMA is not
supported when you do not know that it is not supported.

Perhaps I have made some mistake in my reasoning here.

Andrew.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Kharbas, Kishor
Hi Andrew!

Thanks for the clarification. I understand what you mean now.

I agree if NUMA is supported by the filesystem, it will be very useful and should be made available.
To do that, I have to find if the filesystem supports APIs to serve the same purpose as OS numa calls.

Thanks
-Kishor

> -----Original Message-----
> From: Andrew Haley [mailto:[hidden email]]
> Sent: Tuesday, March 7, 2017 12:36 AM
> To: Kharbas, Kishor <[hidden email]>; hotspot-runtime-
> [hidden email]
> Subject: Re: RFR(M): 8171181: Supporting heap allocation on alternative
> memory devices
>
> On 06/03/17 21:19, Kharbas, Kishor wrote:
> > I don't think there will be failures if that happens. The user needs to be let
> known that NUMA is not supported if he tries to use NUMA in conjunction to
> this flag.
>
> I'm wondering if perhaps I'm not speaking clearly.  Please, let me spell out my
> thinking:
>
> a.  This flag can be used by the DAX filesystem, but can be used by any
> filesystem.
>
> b.  For example, it might be used to put the heap onto a file in, say, a RAM-
> backed file where NUMA is supported.
>
> c.  On such a system, NUMA might be available and useful.
>
> d.  Therefore it is not appropriate to tell people that NUMA is not supported
> when you do not know that it is not supported.
>
> Perhaps I have made some mistake in my reasoning here.
>
> Andrew.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: RFR(M): 8171181: Supporting heap allocation on alternative memory devices

Andrew Haley
On 08/03/17 03:14, Kharbas, Kishor wrote:
> Hi Andrew!
>
> Thanks for the clarification. I understand what you mean now.
>
> I agree if NUMA is supported by the filesystem, it will be very
> useful and should be made available.  To do that, I have to find if
> the filesystem supports APIs to serve the same purpose as OS numa
> calls.

I don't think you have to do anything.  If numa is supported on the
mapped memory range it will work as it is.

Andrew.
Loading...