libjpeg should always use jmemnobs

When using jmem-android with libjpeg, the client has the option
to provide a value for maximum memory usage (or use a default
value) during the decode.  When this value for maximum memory usage
would be exceeded, jmem-android backs data arrays with temp files
to stay below the memory limit.  The CL that defines this memory
limit is at:
https://skia.googlesource.com/skia/+/2295c6332512833760060d803cf6ad19a28adc51
However, it is unclear why the current limit was chosen.

Unfortunately, these temp files are not guaranteed to have unique
names, leading to bugs where multiple arrays are backed up to the
same file.  The original purpose of this CL was to fix this bug.

However, attempting to fix this bug has led to a variety of
additional questions.

The creation of temp files is tricky in this type of library.
Concerns about the creation of temp files include security,
performance of writing to disk, and difficulty of finding the
right directory to use from a library that could be used by an
arbitrary process.

Additionally, there have already been complaints about jmem-android
from the users of the Java API.  b/2791339 explains that writing
to disk is extremely slow, and it causes users of the decoder to
need WRITE_EXTERNAL_STORAGE permission in order to decode.

This led to the creation of jmem-ashmem.c as the memory
implementation for libjpeg to be used by apps.  This acts in the
same way as jmem-android up until the arbitrary maximum memory
usage value is reached.  At this point, jmem-ashmem uses ashmem
to back up the data arrays instead of temp files.

We first considered using jmem-ashmem all the time, since it was
introduced as a faster alternative to jmem-android that does not
require extra permissions and does not have known bugs.

However, thinking further about jmem-ashmem, we feel that it is
not a good alternative.  It is quite odd to solve the problem
of being "out of memory" (having reached the memory limit) by
choosing to allocate more memory.

It seems more intuitive to simply allocate memory on the heap
until we run out or the process is killed.

Using jmemnobs.c follows exactly this approach.  It has no memory
limit and will allocate memory until it runs out or is killed.

Another alternative would be to modify jmem-android to simply
error exit once we reach a maximum memory limit.  This would
make behavior more predicatble, but may prevent us from decoding
images that could possibly be decoded.  This would also bring up
the question of how we choose this maximum memory limit.

BUG:20541233

Change-Id: Iae944ac8588769c3e24f25f64de847e58cc2ad2e
3 files changed
tree: 091c3b851013b7b90d086bd392b6d4172adf2329
  1. Android.mk
  2. ansi2knr.1
  3. ansi2knr.c
  4. armv6_idct.S
  5. cderror.h
  6. cdjpeg.c
  7. cdjpeg.h
  8. change.log
  9. cjpeg.1
  10. cjpeg.c
  11. ckconfig.c
  12. CleanSpec.mk
  13. coderules.doc
  14. config.guess
  15. config.sub
  16. configure
  17. djpeg.1
  18. djpeg.c
  19. example.c
  20. filelist.doc
  21. install-sh
  22. install.doc
  23. jcapimin.c
  24. jcapistd.c
  25. jccoefct.c
  26. jccolor.c
  27. jcdctmgr.c
  28. jchuff.c
  29. jchuff.h
  30. jcinit.c
  31. jcmainct.c
  32. jcmarker.c
  33. jcmaster.c
  34. jcomapi.c
  35. jconfig.bcc
  36. jconfig.cfg
  37. jconfig.dj
  38. jconfig.doc
  39. jconfig.h
  40. jconfig.mac
  41. jconfig.manx
  42. jconfig.mc6
  43. jconfig.sas
  44. jconfig.st
  45. jconfig.vc
  46. jconfig.vms
  47. jconfig.wat
  48. jcparam.c
  49. jcphuff.c
  50. jcprepct.c
  51. jcsample.c
  52. jctrans.c
  53. jdapimin.c
  54. jdapistd.c
  55. jdatadst.c
  56. jdatasrc.c
  57. jdcoefct.c
  58. jdcolor.c
  59. jdct.h
  60. jddctmgr.c
  61. jdhuff.c
  62. jdhuff.h
  63. jdinput.c
  64. jdmainct.c
  65. jdmarker.c
  66. jdmaster.c
  67. jdmerge.c
  68. jdphuff.c
  69. jdpostct.c
  70. jdsample.c
  71. jdtrans.c
  72. jerror.c
  73. jerror.h
  74. jfdctflt.c
  75. jfdctfst.c
  76. jfdctint.c
  77. jidctflt.c
  78. jidctfst.c
  79. jidctint.c
  80. jidctintelsse.c
  81. jidctred.c
  82. jinclude.h
  83. jmemansi.c
  84. jmemdos.c
  85. jmemdosa.asm
  86. jmemmac.c
  87. jmemmgr.c
  88. jmemname.c
  89. jmemnobs.c
  90. jmemsys.h
  91. jmorecfg.h
  92. jpegint.h
  93. jpeglib.h
  94. jpegtran.1
  95. jpegtran.c
  96. jquant1.c
  97. jquant2.c
  98. jsimd_arm_neon.S
  99. jsimd_neon.c
  100. jsimd_neon.h
  101. jutils.c
  102. jversion.h
  103. libjpeg.doc
  104. ltconfig
  105. ltmain.sh
  106. makcjpeg.st
  107. makdjpeg.st
  108. makeapps.ds
  109. makefile.ansi
  110. makefile.bcc
  111. makefile.cfg
  112. makefile.dj
  113. makefile.manx
  114. makefile.mc6
  115. makefile.mms
  116. makefile.sas
  117. makefile.unix
  118. makefile.vc
  119. makefile.vms
  120. makefile.wat
  121. makelib.ds
  122. makeproj.mac
  123. makljpeg.st
  124. maktjpeg.st
  125. makvms.opt
  126. mips_idct_le.S
  127. mips_jidctfst.c
  128. MODULE_LICENSE_BSD_LIKE
  129. NOTICE
  130. rdbmp.c
  131. rdcolmap.c
  132. rdgif.c
  133. rdjpgcom.1
  134. rdjpgcom.c
  135. rdppm.c
  136. rdrle.c
  137. rdswitch.c
  138. rdtarga.c
  139. README
  140. structure.doc
  141. testimg.bmp
  142. testimg.jpg
  143. testimg.ppm
  144. testimgp.jpg
  145. testorig.jpg
  146. testprog.jpg
  147. transupp.c
  148. transupp.h
  149. usage.doc
  150. wizard.doc
  151. wrbmp.c
  152. wrgif.c
  153. wrjpgcom.1
  154. wrjpgcom.c
  155. wrppm.c
  156. wrrle.c
  157. wrtarga.c