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