mmtk
Quarantine the entire heap memory range
Currently, in both Map32 and Map64, we assume MMTk is in control of the entire memory range from heap_start to heap_end. But if the VM uses third-party libraries, they may call mmap and the OS will return a random memory range, which could possibly be within the heap range. This actually happened in some VMs, such as ART.
Although we currently have Mmapper::quarantine_address_range, we only use it for side metadata, but not the memory for objects themselves. On ART, we quarantine the object spaces, too, not just metadata. (@k-sareen, correct me if I am wrong.) We have not seen problems on OpenJDK, but in theory it could happen, too. In JikesRVM, the "malloc returned something that is in RVM address space" error could possibly be caused by malloc getting mmap memory within RVM address space, although we haven't confirmed it, yet.
I suggest mmtk-core should quarantine the entire MMTk heap address range at start-up. For Map64, it is 0x200_0000_0000 to 0x2200_0000_0000, or whatever the VM binding configures at set-up time. It will help ART, and other VMs can avoid potential problems not yet observed.
Because we quarantine the entire heap, it is no longer needed to have the MapState::Quarantined state because it is always quarantined as long as it is within the heap range.
Because we quarantine the entire heap, it is no longer needed to have the MapState::Quarantined state because it is always quarantined as long as it is within the heap range.
Better still keep it. My gut feeling is that there will be cases where we don't want to/can't quarantine addresses.
Right. The problem with ART is that the JIT-compiler also wants addresses to be in the low-4 GB where the heap is. This conflicts with the MMTk spaces. In order to prevent frequent crashes, I quarantine the address range that MMTk may use (i.e. bounded by max heap size). See here.
Because we quarantine the entire heap, it is no longer needed to have the MapState::Quarantined state because it is always quarantined as long as it is within the heap range.
This is still useful for debugging imo. I think we can phase it out slowly if we don't want it.
Better still keep it. My gut feeling is that there will be cases where we don't want to/can't quarantine addresses.
This is still useful for debugging imo. I think we can phase it out slowly if we don't want it.
I mainly worry about the space overhead of maintaining the MapState array for the address range of 0x2200_0000_0000 bytes. Since each chunk is 0x40_0000 (4M) bytes, there will be 0x88_0000 (8.5M) MapState entries to cover . Given the space overhead (which is significant for small scripts or small benchmarks such as luindex/lusearch), we may make it an optional feature. An MMTKOption should be enough, given that it is not used very often except for debugging.
Better still keep it. My gut feeling is that there will be cases where we don't want to/can't quarantine addresses.
This is still useful for debugging imo. I think we can phase it out slowly if we don't want it.
I mainly worry about the space overhead of maintaining the
MapStatearray for the address range of0x2200_0000_0000bytes. Since each chunk is 0x40_0000 (4M) bytes, there will be 0x88_0000 (8.5M)MapStateentries to cover . Given the space overhead (which is significant for small scripts or small benchmarks such as luindex/lusearch), we may make it an optional feature. AnMMTKOptionshould be enough, given that it is not used very often except for debugging.
We could be quarantine the max heap size for each space. The overhead would be reasonable then.
Why do you need to quarantine the entire address range? You only need to quarantine the address range you intend on using. Like Yi said, that's bounded by the max heap size. That's what I'm doing in ART. It doesn't make sense to me to quarantine everything.
We could be quarantine the max heap size for each space. The overhead would be reasonable then.
You only need to quarantine the address range you intend on using.
That makes sense, too. For GenImmix, we'll just quarantine the nursery, immix space, los, immortal space, and non-moving space and the side metadata memory. That should be fewer than 0x2200_0000_0000 bytes.