otp.git - Mirror of Erlang/OTP repository.

Age	Commit message (Collapse)	Author
2014-11-25	[jinterface] cleanup code according to new style	Vlad Dumitrescu

2014-09-11	silence 'potential resource leak' warnings	Vlad Dumitrescu
	OtpInputStream and OtoOutputStream don't need closing (they are ByteArray*Streams)
2014-09-11	don't warn about some unused fields/variables	Vlad Dumitrescu

2014-09-11	keep all method parameters final	Vlad Dumitrescu

2014-09-11	renamed method parameters hiding fields	Vlad Dumitrescu

2014-09-11	remove unused variables	Vlad Dumitrescu

2014-09-11	removed unnecessary semicolons, imports, labels	Vlad Dumitrescu

2014-06-08	Fix a few javadoc errors	Anthony Ramine
	Reported-by: Boris Mühmer
2014-02-11	jinterface: implement support for maps	Vlad Dumitrescu
	The API and implementation are simplistic, like for lists and tuples, using arrays and without any connection to java.util.Map.
2013-02-13	Merge branch 'nk/jinterface_dont_compress_if_size_increased/OTP-10822'	Fredrik Gustafsson
	* nk/jinterface_dont_compress_if_size_increased/OTP-10822: jinterface, OtpOutputStream: add a write_compressed(object, level) method jinterface: fix a memory leak jinterface: new limited OutputStream implementation without the need to resize jinterface: don't return compressed external term if bigger than uncompressed jinterface: don't compress small erlang terms < 5 bytes jinterface, OtpOutputStream: properly override the three write() methods to ensure our growth strategy jinterface: fix typo in error message if encoding fails jinterface: don't need another FilterOutputStream wrapper
2013-02-04	jinterface, OtpOutputStream: add a write_compressed(object, level) method	Nico Kruber
	Now that we use an own deflater, we can also allow the user to specify the compression level as in Erlang's term_to_binary/2.
2013-02-04	jinterface: fix a memory leak	Nico Kruber
	after the first try to compress the value with a fixed buffer size, the deflater must be closed so that memory can be (instantly) reused
2013-02-04	jinterface: new limited OutputStream implementation without the need to resize	Nico Kruber
	(saves memory re-allocations)
2013-02-04	jinterface: don't return compressed external term if bigger than uncompressed	Nico Kruber
	Now, OtpOutputStream#write_compressed() uses the same mechanism as erts_term_to_binary() in external.c: it tries to compress the given term into a buffer of the size of the uncompressed term and if this is not possible, i.e. the compression plus headers is bigger, it uses the uncompressed external term format instead.
2013-02-04	jinterface: don't compress small erlang terms < 5 bytes	Nico Kruber
	Compression always has at least 5 bytes (the compressed tag + original size) so we can't get a smaller external term if the original term is already smaller than 5 bytes.
2013-02-04	jinterface, OtpOutputStream: properly override the three write() methods to ↵	Nico Kruber
	ensure our growth strategy Previously, if code called e.g. write(byte[] b, int off, int len), the growth strategy of the parent class ByteArrayOutputStream was used.
2013-02-04	jinterface: fix typo in error message if encoding fails	Nico Kruber

2013-02-04	jinterface: don't need another FilterOutputStream wrapper	Nico Kruber
	DeflaterOutputStream is already an FilterOutputStream
2013-01-25	Update copyright years	Björn-Egil Dahlberg

2013-01-16	Implement UTF-8 atom support for jinterface	Rickard Green

2011-12-09	Update copyright years	Björn-Egil Dahlberg

2011-12-09	restore Java5 compatibility	Nico Kruber

2011-12-09	JInterface: improve OtpOutputStream buffer allocation	Nico Kruber
	Previously, the buffer was increased linearly by 2048 bytes. I now propose to use an exponential increase function (similar to Javas ArrayList, e.g. always at least +50%). This significantly increases performance of e.g. doRPC for large parameters as the following comparison illustrates (shown is the buffer size after each time, the buffer has reached its limit): n n2048 (n3)/2+1 (n3)/2+1 (at least +2048) 1 2,048 2,048 2,048 2 4,096 3,073 4,096 3 6,144 4,610 6,145 4 8,192 6,916 9,218 5 10,240 10,375 13,828 6 12,288 15,563 20,743 7 14,336 23,345 31,115 8 16,384 35,018 46,673 9 18,432 52,528 70,010 10 20,480 78,793 105,016 11 22,528 118,190 157,525 12 24,576 177,286 236,288 13 26,624 265,930 354,433 14 28,672 398,896 531,650 15 30,720 598,345 797,476 16 32,768 897,518 1,196,215 17 34,816 1,346,278 1,794,323 18 36,864 2,019,418 2,691,485 19 38,912 3,029,128 4,037,228 20 40,960 4,543,693 6,055,843 21 43,008 6,815,540 9,083,765 22 45,056 10,223,311 13,625,648 23 47,104 15,334,967 20,438,473 24 49,152 23,002,451 30,657,710 25 51,200 34,503,677 45,986,566 26 53,248 51,755,516 68,979,850 27 55,296 77,633,275 103,469,776 28 57,344 116,449,913 155,204,665 29 59,392 174,674,870 232,806,998 30 61,440 262,012,306 349,210,498 Actually, ArrayList uses the (n3)/2+1 strategy. In order not to decrease performance for messages <10k, we could keep the (public) OtpOutputStream#defaultIncrement constant and let the buffer always increase by at least this much (third column). In order to create a buffer of 1MB, now only 16 array copies are needed vs. (1024*1024/2048)=512 array copies for the linear increase function. If a user sends a message of 10MB size, this is 22 vs. 5120 copies. NOTE: the meaning of the "public static final int defaultIncrement" member has changed a bit with this implementation (API compatibility?) - why was this public in the first place?
2009-11-20	The R13B03 release.OTP_R13B03	Erlang/OTP