Skip to content
Snippets Groups Projects
  • Glauber Costa's avatar
    4eb7d9c2
    balloon: fix the double move problem · 4eb7d9c2
    Glauber Costa authored
    
    As we have recently discovered, some parallel GCs will move an object to two
    different locations at times, and later on decide on which one to use. This
    breaks our implementation if the final object is the second one to be copied,
    because by then the original region is already mapped - so we won't fault, and
    the unmapped region will not be the actual balloon, so we will have a bogus
    fault
    
    The core of this solution is to keep all the regions unmapped. Because they had
    only garbage before, we know Java shouldn't read anything from it before it
    writes something new. And when it does that, we declare that to be no longer a
    balloon.
    
    Movement is then split in two phases: the normal phase, and the finish phase.
    In the finish phase we will remove the old VMA and create the new VMA again,
    with heap characteristics.
    
    Special care needs to be taken when "conciliating" the array: because we use
    the difference between first faulting address and original array address to
    calculate how many bytes we are skipping, we need to store that information
    somewhere. We're using an unordered_map (hash) for that. We'll keep track of
    all in-flight ballooned regions and hold the original address of the array.
    
    When we detect movement *from* that region, we know it is the new location
    and update the balloon object with the new address.
    
    Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
    Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>
    4eb7d9c2
    History
    balloon: fix the double move problem
    Glauber Costa authored
    
    As we have recently discovered, some parallel GCs will move an object to two
    different locations at times, and later on decide on which one to use. This
    breaks our implementation if the final object is the second one to be copied,
    because by then the original region is already mapped - so we won't fault, and
    the unmapped region will not be the actual balloon, so we will have a bogus
    fault
    
    The core of this solution is to keep all the regions unmapped. Because they had
    only garbage before, we know Java shouldn't read anything from it before it
    writes something new. And when it does that, we declare that to be no longer a
    balloon.
    
    Movement is then split in two phases: the normal phase, and the finish phase.
    In the finish phase we will remove the old VMA and create the new VMA again,
    with heap characteristics.
    
    Special care needs to be taken when "conciliating" the array: because we use
    the difference between first faulting address and original array address to
    calculate how many bytes we are skipping, we need to store that information
    somewhere. We're using an unordered_map (hash) for that. We'll keep track of
    all in-flight ballooned regions and hold the original address of the array.
    
    When we detect movement *from* that region, we know it is the new location
    and update the balloon object with the new address.
    
    Signed-off-by: default avatarGlauber Costa <glommer@cloudius-systems.com>
    Signed-off-by: default avatarPekka Enberg <penberg@cloudius-systems.com>