Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: rubinius/rubinius
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 5241d53f1844
Choose a base ref
...
head repository: rubinius/rubinius
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 0c24d0471f2d
Choose a head ref
  • 2 commits
  • 5 files changed
  • 1 contributor

Commits on Jul 22, 2016

  1. Copy the full SHA
    203a378 View commit details
  2. Fixed 32-bit code assumption. Fixes #3682.

    When allocating an Array of size 2**29, Rubinius would allocate a Tuple big
    enough to hold 2**29 == 536870912 elements. On a 64bit arch, each of these
    elements require sizeof(intptr_t) == 8 bytes. A Tuple memory header is 4 *
    sizeof(intptr_t) == 32 bytes. So, we have 2**29*8+32 == 4294967328. It's a big
    number, but not so big that the 64bit arch can't easily handle it.
    
    Unfortunately, down in the managed memory code, there was an explicit uint32_t
    data type. What happens when 4294967328 == 0x100000020 bytes get put into
    32bits? 0x100000020 & 0xffffffff == 32. Those 2**29 elements were being
    crammed into 32 bytes. Computers may be magic, but even they can only take so
    much.
    brixen committed Jul 22, 2016
    1
    Copy the full SHA
    0c24d04 View commit details
Loading