Details

    • Type: Improvement
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: planned but not scheduled
    • Component/s: Build
    • Labels:
      None
    • Environment:
      Debian Squeeze, 2.6.32-5-kirkwood, Sheevaplug, ARMv5

      Description

      Since the upcoming social network Diaspora* uses mongodb as backend it would be nice to have it running on little home servers such as the Sheevaplug. As such servers are often based on ARM-architecture mongodb needs support for this.

      1. armdoubles.diff
        4 kB
        Jani Monoses
      2. mongi.diff
        2 kB
        Jani Monoses
      3. mongoarm.diff
        8 kB
        Jani Monoses

        Issue Links

          Activity

          Hide
          acm Andrew Morrow added a comment - - edited

          Hi All -

          Earlier this week, a major roadblock for portability to non-x86 platforms was resolved. For some time, we have been stuck using an old version of the V8 Javascript interpreter because newer V8 versions removed critical memory management facilities that we depended on to constrain resource utilization during server side Javascript execution. While newer versions of V8 had added ARM support, the version on which we were pinned did not have those changes. However, on Tuesday, we committed experimental support for building with SpiderMonkey. SpiderMonkey both provides the resource management facilities that we require, and we anticipate, though have not yet confirmed, that it will not represent a barrier to portability like old V8 engine did.

          The next development release, 3.1.6, will contain the new SpiderMonkey interpreter as an opt-in, however, our initial integration will only have build information encoded for how to target x86. If you are interested in trying to build with SpiderMonkey on other platforms, please reach out to the development team on mongodb-dev and we can provide guidance on how to configure SpiderMonkey on those platforms, or for any other portability issues. To build with the new interpreter, invoke scons with the --js-engine=mozjs flag.

          Please note that currently we only officially target, test, and release for x86, and we are aware of latent endian, aliasing, and alignment issues in the codebase in general, and in the storage engines in particular. These issues may or may not adversely affect ports to other processors, depending on their endianness and sensitivity to alignment. We are working to resolve these issues, however fixing them is not an explicit release goal for the upcoming 3.2 stable. Additionally, there are likely to be issues with the build system, which has not been well tested on non-x86 systems.

          For examples of some of these types of issues, please see SERVER-19427, SERVER-19430 and SERVER-19431.

          Show
          acm Andrew Morrow added a comment - - edited Hi All - Earlier this week, a major roadblock for portability to non-x86 platforms was resolved. For some time, we have been stuck using an old version of the V8 Javascript interpreter because newer V8 versions removed critical memory management facilities that we depended on to constrain resource utilization during server side Javascript execution. While newer versions of V8 had added ARM support, the version on which we were pinned did not have those changes. However, on Tuesday, we committed experimental support for building with SpiderMonkey . SpiderMonkey both provides the resource management facilities that we require, and we anticipate, though have not yet confirmed, that it will not represent a barrier to portability like old V8 engine did. The next development release, 3.1.6, will contain the new SpiderMonkey interpreter as an opt-in, however, our initial integration will only have build information encoded for how to target x86. If you are interested in trying to build with SpiderMonkey on other platforms, please reach out to the development team on mongodb-dev and we can provide guidance on how to configure SpiderMonkey on those platforms, or for any other portability issues. To build with the new interpreter, invoke scons with the --js-engine=mozjs flag. Please note that currently we only officially target, test, and release for x86, and we are aware of latent endian, aliasing, and alignment issues in the codebase in general, and in the storage engines in particular. These issues may or may not adversely affect ports to other processors, depending on their endianness and sensitivity to alignment. We are working to resolve these issues, however fixing them is not an explicit release goal for the upcoming 3.2 stable. Additionally, there are likely to be issues with the build system, which has not been well tested on non-x86 systems. For examples of some of these types of issues, please see SERVER-19427 , SERVER-19430 and SERVER-19431 .
          Hide
          kim3er Richard Kimber added a comment -

          Thanks @Andrew, that really good news!

          Show
          kim3er Richard Kimber added a comment - Thanks @Andrew, that really good news!
          Hide
          radamanth Tony DEBOSCHERE added a comment -

          Thanks ! Looking forward to it

          Show
          radamanth Tony DEBOSCHERE added a comment - Thanks ! Looking forward to it
          Hide
          dan@littlegenius.io Daniel Rosenberg added a comment -

          With the strong trend of ARM microserver in the cloud space (see ovh, scaleway, HP, datacentred,...) with low TCO, support of ARM v7 and v8 is very welcome. +10. Really looking forward to it.

          Show
          dan@littlegenius.io Daniel Rosenberg added a comment - With the strong trend of ARM microserver in the cloud space (see ovh, scaleway, HP, datacentred,...) with low TCO, support of ARM v7 and v8 is very welcome. +10. Really looking forward to it.
          Hide
          acm Andrew Morrow added a comment -

          Hi Daniel Rosenberg - Please note that official support for ARM v7 is unlikely. The MMAPv1 storage engine is limited to ~1GB of journaled data on 32-bit systems, and the WiredTiger storage engine is 64-bit only. Effectively, this means that any future ARM port will only target Aarch64.

          Show
          acm Andrew Morrow added a comment - Hi Daniel Rosenberg - Please note that official support for ARM v7 is unlikely. The MMAPv1 storage engine is limited to ~1GB of journaled data on 32-bit systems, and the WiredTiger storage engine is 64-bit only. Effectively, this means that any future ARM port will only target Aarch64.

            Dates

            • Created:
              Updated:
              Days since reply:
              1 day ago
              Date of 1st Reply: