eh - yes - ouch! 21 bit cannot occur (char = 16 bits)
please, please ignore my comment about it.
Am 07.02.2014 um 00:15 schrieb Xueming Shen :
> Modified UTF8 has to be used, as specified by the spec.
>
> http://download.java.net/jdk8/docs/api/java/io/DataInput.html#modified-utf-8
>
> -Sherman
Modified UTF8 has to be used, as specified by the spec.
http://download.java.net/jdk8/docs/api/java/io/DataInput.html#modified-utf-8
-Sherman
On 02/06/2014 02:50 PM, Robert Stupp wrote:
>>> -Chris.
>>
Hi,
I looked into the UTF serialization and deserialization code - and compared it
a bit with the code behind "new String(byte[], Charset)",
"String.getBytes(Charset)".
Just to find something that can be safely reused in Object*Stream classes to
optimize String handling.
The first thing I noti
Thanks Peter, this is a nice improvement. I’ll incorporate your changes before
pushing.
-Chris.
On 5 Feb 2014, at 16:39, Peter Levart wrote:
> On 02/05/2014 04:11 PM, Chris Hegarty wrote:
>> Thanks stuart, Mike, and Paul.
>>
>>> - Why not have getClassSignature() return an interned string? (t
On 02/05/2014 04:11 PM, Chris Hegarty wrote:
Thanks stuart, Mike, and Paul.
- Why not have getClassSignature() return an interned string? (that's if
interning is actually essential. Are we sure it's not just overhead?)
I didn’t want to change the existing use of interning here, just refactor
Thanks stuart, Mike, and Paul.
> - Why not have getClassSignature() return an interned string? (that's if
> interning is actually essential. Are we sure it's not just overhead?)
I didn’t want to change the existing use of interning here, just refactor the
code a little to make it cleaner.
> I
On Feb 3, 2014, at 11:01 PM, Stuart Marks wrote:
> Nobody took the bait on this yet? :-)
>
> Certainly there's a lot of semi-myth on this topic, on both sides. Here's my
> source of mythology (or urban legend, as one might have it):
>
> http://www.ibm.com/developerworks/java/library/j-jtp0927
Nobody took the bait on this yet? :-)
Certainly there's a lot of semi-myth on this topic, on both sides. Here's my
source of mythology (or urban legend, as one might have it):
http://www.ibm.com/developerworks/java/library/j-jtp09275/index.html
My concern here is not so much about leaking of
One would have to measure of course, but intuitively, it seems like a good
change to reuse the stringbuilder. There's also the issue that the local
stringbuilder before was default-sized, and for large content, it would
generate even more garbage as the underlying array is expanded.
The "temporar
t;> + if (c <= 0x007F && c != 0) {
>>> +write(c);
>>> +} else if (c > 0x07FF) {
>>> +write(0xE0 | ((c >> 12) & 0x0F));
>>> +write(0
On 31 Jan 2014, at 19:07, Stuart Marks wrote:
> On 1/31/14 10:46 AM, Chris Hegarty wrote:
>> I think your patch can be split into two logical, independent, parts. The
>> first is the use of unsafe to access the String UTF length. The seconds is
>> to reuse, where possible, the existing StringBui
On 1/31/14 10:46 AM, Chris Hegarty wrote:
I think your patch can be split into two logical, independent, parts. The
first is the use of unsafe to access the String UTF length. The seconds is
to reuse, where possible, the existing StringBuilder instances, skipping of
primitive/object reading/writi
>
> Robert
>
>
> Gesendet: Freitag, 31. Januar 2014 um 15:22 Uhr
> Von: "Chris Hegarty"
> An: "Robert Stupp" , core-libs-dev-request
>
> Betreff: Re: Aw: Re: ObjectIn/OutputStream improvements
> Hi Robert,
>
> I think your patch can b
.toString();
>> diff --git a/src/share/classes/java/io/ObjectStreamClass.java
>> b/src/share/classes/java/io/ObjectStreamClass.java
>> --- a/src/share/classes/java/io/ObjectStreamClass.java
>> +++ b/src/share/classes/java/io/ObjectStreamClass.java
>> @@ -1474,7 +1474,28 @@
>> /*
I found another location in OOS code that might be an optimization point:
In java.io.ObjectOutputStream.BlockDataOutputStream#write(byte[], int, int,
boolean) the first lines look like this:
if (!(copy || blkmode)) { // write directly
drain();
On 15 Dec 2013, at 10:29, Robert Stupp wrote:
> Hi,
>
> I digged through the object serialization code and found some lines that
> could be optimized to reduce the number of calls to System.arraycopy() and
> temporary object allocations especially during string (de)serialization.
> In short se
16 matches
Mail list logo
