java.time.ZoneId.systemDefalut() overhead

[Peter Levart]

On 02/27/2015 12:10 AM, Peter Levart wrote:
> On 02/26/2015 11:47 PM, Stephen Colebourne wrote:
>> Personally, I found the SharedSecrets version easier to follow. I also
>> suspect that the toZoneId0() method would be invoked most of the time
>> with this variant, resulting in no beneficial inlining effect.
>
> Not true. Once the toZoneId0() invokes baseZone.toZoneId() (on the 
> base instance which is attached to defaultTimeZone static field) the 
> ZoneId object will be set on both instances (base and clone). Next 
> call to TimeZone.getDefault() will create another clone of default 
> TimeZone, but this time, the cloned zoneId field will already point to 
> cached ZoneId. That and EA-based elimination of clone's allocation 
> makes this variant as performant as SharedSecrets based.
>
> But I agree that it is not simple to follow all the possible code 
> paths. The benefit is that java.time is not dependent on ShareSecrets.

Here's another variant that doesn't use a back link to base TimeZone:

http://cr.openjdk.java.net/~plevart/jdk9-dev/ZoneId.systemDefault/webrev.03/

I think it's easier to follow than previous one.


Regards, Peter