However, for the past little bit, I have been battling a rather unfortunate situation (which admittedly is not all their fault) regarding Ubuntu upgrades and their (ve) servers. My site currently runs on a Media Temple (ve) hosting virtualized Ubuntu 10.04.4 LTS. I had been doing regular upgrades and dist-upgrades on this environment without fail, but I hit an issue where some of the packages in the Lucid Apt repos were just getting a little long in the tooth. I generally use Ruby, Nginx, and a few other things out there that have a tendency to move pretty quickly on their upgrades, and individual releases generally don’t introduce the major/minor package version upgrades of the sort that might happen with some of these components. Two and a half years can be a long time when it’s a server for a hobbyist exploring a lot of new tech.

Now, I do know that with Ubuntu’s community, you can inevitably dig up somebody who has a PPA that can be tied to your respective LTS install to individually bring in packages up to a newer version than that particular major release ships, but inevitably those are supported less effectively than the mainline distro packages, and there’s also a spidering of trust it results in, where you being relying on more than just “official” community package maintainers. This is, in fact, what I’ve had to do, however.

Choosing to leave the LTS wasn’t a huge deal for me anyway, as this is my personal server; not some commercially-hosted product. So, I decided to do the magical do-release-upgrade to level-up. Whoops.

Earlier last year if you decided to do a release-upgrade on Media Temple (ve)s with “normal” as your release profile (as specified in the /etc/update-manager/release-upgrades file), it would upgrade you to 10.10, and everything was shiny. You could then upgrade to 11.04, and even to 11.10. No problems.

However, if you tried to go to 12.04, the upgrade bombed very, very badly. In short, this is the error I received.

Please check your current kernel version with uname -r. If it is less than 2.6.24, the upgrade will fail half-way with a glibc error. That happens because the glibc included by default with 12.04 requires a minimum 2.6.24 kernel – glibc are the critical C libraries used by every application.

Yup - sure enough, just as this link indicates, MediaTemple runs an OpenVZ-based virtualization by Parallels. Here’s my uname -r:

2.6.18-028stab101.1

Uh-oh. 2.6.18 is definitely not 2.6.24. The forum Q&A above suggests a rather ominous pinned dependency for glibc. I tried this temporarily, but never got it to work, and decided that it was not something I wanted to be shimmed on my server long-term anyway, so I went back to 10.04.

(Incidentally, this isn’t discussed much, but if an Ubuntu upgrade fails, you better have a spare boat handy, as this one is going to sink, and no bailing of water will help. It’s very difficult to do anything resembling a rollback without just restoring a backup. So be prepared!)

Now, something else happened shortly after 12.10 Ubuntu came out last year that made all of this muddier for Media Temple Ubuntinians. While 10.10 has been EOL for a while, it hasn’t actually been moved off of the main APT sources, so doing a “normal” upgrade would work as you’d expect. Through some administrative cleanup (I presume), it’s now properly under “old-releases” on the Ubuntu site. So if you try to upgrade from 10.04 LTS to 10.10 with do-release-upgrade and a normal upgrade setting, you will get a rather obscure 404 error. Worse, because Lucid isn’t actually in the EOL package tree for standard builds (because it’s not EOL), the general recommendation for upgrades fails (see here). In short, they recommend you to:

1. Move your current release sources to old-releases
2. Do a full “update+upgrade” to get caught up
3. Perform the do-upgrade-release to the next version, which may be EOL.

This doesn’t work, as step-2 throws 404 errors. Now, I suspect so long as you did a full update before moving this over (flip steps one and two) it probably would work. But it feels rather unpleasant, and inevitably you’ll still hit 11.10 and have to stop. So now you’ve upgraded to a more recent build, but you’re no longer on an LTS release, and instead are on a release that will likely sunset in April, 2013, with nowhere to go.

Even worse for most (ve) folks is the fact that the default upgade process is not to do a “normal” release, but to do an LTS upgrade on 10.04 now that 12.04 is out. So if you login to your Media Temple instance, it will suggest you upgrade to Precise, and if you do -BOOM- trashed install. I made that mistake as well during this process.

So in short, 10.04 LTS is probably the best you can do on a (ve) without doing some less-than-ideal workarounds, and the kernel is going to be 2.6.18 until Media Temple straightens it out.

To describe how old 2.6.18 actually is, 2.6.16 (just 2 patches prior) came out in March of 2006. 2.6.27, which came out over a year after was, at release, a long-term-support kernel for Linux - and even that was EOL’ed back in early 2012.

Now, to defend Media Temple a little bit, Ubuntu 10.04 LTS is still in active support, and will be for some time. So my distro is totally acceptable, even if the (admittedly, heavily patched and customized) kernel their virtualization uses is EOL. Also, from what I’ve been able to determine, this was originally a problem with Parallels, and not Media Temple. Unfortunately, it’s been something of a lacking priority for them, or at least not very transparent that it was a priority. Here is a forum thread that’s been going on since shortly after 12.04 went live: Ubuntu 12.04 LTS on Media Temple (ve).

Here are the most recent updates from Media Temple - November 6th of last year:

We still don’t have a time frame as to when Ubuntu 12.04 LTS will be available for the (ve) Servers. The ‘technical obstacle’ is we are bringing in a whole new infrastructure for our (ve) Servers. I apologize for the inconvenience but this is all the information I have for you at the moment.

… and on January 11th this year:

Hey there! Apologize for the inconvenience but we currently don’t have any update on when Ubuntu 12.04 LTS will be available.

I even decided to bring this up with the Media Temple twitter team, and got a similar non-commital response unfortunately: https://twitter.com/realjenius/status/298973645991182337.

But, even with bad news comes good. The main reason for the delay seems to be that they are working on some rather large (and non-descript) infrastructural change for the (ve) servers. The one huge benefit so far is that they doubled their RAM offering for all (ve) tiers, and existing customers were allowed to upgrade with a simple push of a button. So I guess I shouldn’t complain too much!

This is an interesting JEP as it proposes no Java consumer-oriented APIs; the only changes would be on the sun.misc.Unsafe class - which is already a fascinating pivot point for many of the advanced concurrency features of Java. Here is a Stack Overflow article that recaps many of them better than I could: StackOverflow.com: “Interesting Uses of sun.misc.Unsafe”. This class (as you can guess from the package) is not intended for regular Java devs to access; it’s an implementation-specific class, and is really only meant for internal use by class library devs on the JDK. (That said, many folks have taken this class by the horns to wrangle the most out of the JVM anyway.)

What is proposed instead is to make ordering fences with memory a first-class citizen in the implementation layer of the JDK so that the various core APIs for concurrency can leverage fencing without having to resort on side-effects of other lower-level intrinsics (something that is done regularly today).

You may be asking why memory fencing is important. Modern CPUs can easily re-order memory accessing and storing when it can see via the upcoming instruction set that re-ordering will not impact the overall outcome of the program as considered by a single thread in the CPU. When you start throwing multiple threads or CPUs at a problem, out-of-order operations on memory that would otherwise go un-noticed could instead cause all kinds of data corruption and confusion. That’s why effectively all of the core synchronization and atomic operations in Java today implicitly carry a memory fence along with them; it’s part of the larger equation of protecting memory access.

This JEP includes three operations in the proposal:

• Unsafe.loadFence() - Prevent reordering of load operations before this call with loads and stores after this call.
• Unsafe.storeFence() - Prevent reordering of store operations before this call with loads and stores after this call.
• Unsafe.fullFence() - Prevent reordering of all memory operations before this call with loads and stores after this call.

You can read more about memory fences in the Wikipedia Memory Barrier article.

It’s worth noting that the JEP does consider potentially surfacing memory fence operations to full devs at some point in the future given that sun.misc.Unsafe is already platform specific (making it risky for external libs to access), and may become impossible to access given the efforts of Jigsaw:

Adding these methods at the VM level permits use by JDK libraries in support of JDK 8 features, while also opening up the possibility of later exporting the base functionality via new java.util.concurrent APIs. This may become essential to allow people developing non-JDK low-level libraries if upcoming modularity support makes these methods impossible for others to access.

MBeans give us a tremendous amount of access into the running system, and are a good standardized way to publish the management tools. Unfortunately, they are a tremendous pain in the ass to get access to in a secure system.

Generally what I am given for any system we connect to is my own SSH key or SSH credentials, and possibly one or two ports popped open with pinholes for my IP address. The latter I can provide for myself with SSH tunnelling if I need to. Unfortunately, this isn’t enough for JMX.

JMX runs on top of RMI, and as such, there are two ports that JMX utilizes:

• The JMX connect port.
• The (infamously) roaming RMI data port.

In all recent builds of Oracle Java, you can affix the first port via this system property when starting the Java program:

-Dcom.sun.management.jmxremote.port=1099

Unfortunately, the second port has no mechanism for assignment. This means that you either need (a) the entire firewall cracked wide open for your IP address, or (b) you need to run a dynamic socks proxy and route your particular JMX tool through the proxy. The latter is generally the only real option. You then have the added complexity that the hostname you connect to needs to match the value of java.rmi.server.hostname, which in cloud solutions that do complex things with IP addresses (I’m looking at your EC2), only makes it even harder to get right.

Thankfully (and I do mean thankfully), not anymore for systems running Java 7u4 or higher. Marcus Hirt has blogged about the new RMI binding property that has come to Java since the merger with JRockit.

Now, one handy but often overlooked feature that entered the 7u4 JDK as part of the JRockit convergence, was the ability to specify the port of the RMI server. By setting the port used by the RMI registry and the RMI server to the same port, tunneling will be much easier. Now, the name of the property for setting the port of the RMI Server was slightly changed from the JRockit implementation, and is now called com.sun.management.rmi.port, instead of com.sun.management.rmiserver.port. Here is an example of how to enable the external management agent with the same RMI registry and RMI server port on the command line, in JDK 7u4 and later:

java -Dcom.sun.management.jmxremote.port=7091 -Dcom.sun.management.jmxremote.rmi.port=7091 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false

I cannot stress enough how much this should help those of us dealing with firewalled systems and JMX. Kudos!

Elementary OS Luna Beta 1

One of the most watched Linux distros for some time has been Elementary. A number of GTK themes have come out of the work on the OS that have been some of the most well received in the Linux community.

This week Luna Beta 1 came out, and it’s had a surprisingly positive number of reviews. Mine can be included in that. I have only installed it this weekend, but am already quite impressed with the polish and performance it has in comparison to Ubuntu 12.10.

Since Elementary is built on top of the Ubuntu platform, it benefits from the significant amount of packaging and community work that Ubuntu benefits from, and then there is simply an additional layer of polish and smart bundling of software that simply makes it feel like a much more complete and comfortable OS.

Now, that’s not to say it’s without bugs. I’ve had a few myself, including Noise (the custom media app) being unable to sync my music folder properly without crashing, and a number of system crash dialogs - but they have been relatively sparse so far. Overall, apps I’m used to having problems with in Linux (like Skype), have just worked; quite surprisingly.

Monday will be the first real test, as I will be entering the workforce with it full-time. So far, however, color me impressed!

A Variety of Steam News

Steam was officially launched to 1000 lucky folks on 11/06, and is starting to really pick up some… pressurized evaporated water. On Friday, the Valve folks announced 500 additional slots in their BETA, slowly but surely expanding the test base.

It should be noted that 60,000 people signed up for the initial BETA, which is not a paltry number. It’s an encouraging sign that there is at least some viability there.

In addition to 500 people being in the list, Friday also saw the official unveiling of Big Picture mode on the Linux client, which some have seen as an opportunity for console-like gaming from Linux (assuming, of course, that ‘if you build it, the games will come’ holds true).

As I mentioned previously, the initial release had about 25 games, most of which were indie games that for one reason or another were already cross-platform and available through other channels, like Humble Indie Bundle. That list has been gradually expanding over the last week, with a variety of other indie games and greenlight games coming alive. Which leads into the next topic…

Unity 3D 4.0 - Now Runs on Linux

One of the single most popular game engines right now is Unity (not to be confused with Ubuntu Unity). My company works with a ton of clients using this as their gaming platform, and there are a number of good reasons why; not the least of which is the huge number of platforms it supports out of the box.

The 4.0 release includes preview support for generating Linux binaries, which is a huge boon for Linux, as it effectively brings the porting effort down to zero. Since most Unity games don’t have any platform-specific code, it’s very easy to just generate the Linux distro to get the extra coverage.

Skype 4.1

Microsoft released Skype 4.1 this week for Linux, bringing with it support for integration with the Messenger IM service.

This isn’t particularly notable as an individual release, but it does seem to further solidify the commitment (from Microsoft nonetheless!) to deliver a consistent, and hopefully quality, Skype client for Linux. Something those of us who use it for our jobs will appreciate.

Netflix (Kinda!)

Finally, folks finally got Netflix (in all its Silverlight DRM glory) running on Linux via use of Firefox running through Wine. It apparently was quite a chore to get working; but you’ve gotta love the ingenuity of people.

There are a number of enhancements being proposed in this JEP, so I’ll probably tackle it in a few blog posts. For today, we’ll talk numbers!

Atomic-ish Numbers

It’s very very common to use atomic values in metrics gathering capacities in Java application. Applications everywhere (if they know what is good for them) are doing things like tracking total execution time, # of executions, and max execution time for as many data points as they can stomach.

Compared to the “olden days” of Java, atomics (particularly java.util.concurrent.atomic.AtomicLong) are a huge boon for this as they get rid of the overhead caused by contention when you’re dealing with synchronization. A particular code-flow will be much more concurrent when updating an atomic value than trying to fence through a synchronization boundary in heavy traffic.

However, all is not well in atomic land. While they are much better than everything that has come before them, they can still be quite disruptive. Updating an atomic value is, by definition, still fully shared between threads. While it’s a narrow operation, the guarantee is that after the operation is done, all CPU active on the system will see the same value in that memory location. To do this, the CPU core doing the work has to ensure that the value of that atomic is pushed back out to main memory; not just retained in the CPU cache. And in so doing, it has to keep trying to update the core memory until the incremental is what is expected (via a CAS - compare and swap operation). This CAS and memory fence ensures that staleness does not happen due to the CPU keeping data in local cache only, and not dumping out to slow system memory constantly.

However, this inherently means that, for this value, we are writing out to slow system memory constantly. So it’s not free. Additionally, what often can happen is that the atomic changing invalidates a line of cache shared by multiple values. This is fairly common because the contiguous cache blocks the CPU is designed to invalidate are generally large enough to hold multiple numeric values. This means that the CPU is forced to (unintentionally) re-fence multiple atomics; often atomics that are allocated together for the same data structure.

This lack of cache coherence and affinity can be a very real, and very hidden cost with all fence operations. Martin Thompson and Michael Barker (the wizards behind the much discussed LMAX Architecture and the disruptor stream processing framework) have a talk that covers this problem (and many others) in detail titled Lock-Free Algorithms.

Thompson and Barker show exactly how much this cache issue can impact performance, and how with a little adjusting, the atomic classes can be designed with what they call “mechanical sympathy” in mind; in other words, built to avoid sharing cache regions with other atomic values. So instead of this:

cache line 1 . . . . <atomic int val A> . . . . . <atomic int val B> . . .
cache line 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

You ideally would get this:

cache line 1 . . . . <atomic int val A> . . . . . . . . . . . . . . . . .
cache line 2 . . <atomic int val B> . . . . . . . . . . . . . . . . . . .

Now the two values are isolated from each other, reducing cache damaging significantly.

While I’m listing interesting related reads, another article just popped up in the past couple days that shows some very real metrics for the problems you can hit with Atomics in terms of program throughput. Marc Brooker just posted how atomics and volatiles in Java work on x86, and it shows exactly what a lack of mechanical sympathy can mean to your cache hit performance. The perf stat output he shows with the significant increase of LLC-load-misses is exactly what this padded cache is meant to mitigate as much as possible - of course, it can only do so much; the entire idea of an atomic implies there is some shared memory involvement, which is simply going to be slower. The goal is to narrow that slowness to specific values, as much as possible.

So mechanical sympathy changes help, but only get you so far. The work in JEP-155 doesn’t stop by exploring this idea. There is another issue with atomics as it pertains to being used for metrics-like monitoring in large scale Java systems. Their atomic requirement may actually be too stringent. Often times when you’re looking at something like an “average” execution time or “max” execution time, it’s acceptable to say the value can be eventually consistent across multiple updates. If there is a little margin for error (like you might miss one recent update on a read), it’s not going to impact your analysis in any real way.

Knowing this, the JSR166 folks have taken one of the ideas that are common in highly concurrent programming, and applied them to these types: striping, or segmenting.

If you’ve ever looked into the internals of the ConcurrentHashMap class, you may be familiar with the constructs it uses to minimize contention and avoid locking. Internally, the CHM uses a series of segments which represent sub-sections of the map, and can be worked with independently. By using multiple segments, the data structure is able to immediately divide the potential contention, at the expense of a little more memory used.

(Incidentally, the fastest JDBC connection pool I’ve ever benchmarked at scale uses this same mechanic to avoid pool contention - see BoneCP.)

This same idea is in place for a number of new atomic classes. There is an abstract Striped64 super-class that holds a collection of Cell objects, which are really just Atomics with special padding to help with mechanical sympathy. The cells are created lazily as CAS updates fail due to contention. What this means is that a single instance of this may have several internal atomics representing the value in the aggregate. Since this class doesn’t just sit on the CAS wall until it updates successfully, it doesn’t have the same repeated crawling down into shared memory from the CPU cache. Instead it will retry a set number of times, and if it can’t get the first cell to update, it creates another one. The next one is a fully separate atomic in memory, and is bound by its own memory fencing and contention.

What’s interesting about this is since the atomics are intentionally written to avoid cache collisions, each one can be independently represented on a CPU, and since the class will try to balance the cells to individual threads, it will avoid causing the painful contentious updates altogether, making the most valuable use of the atomics. Each thread can say “If I created a new cell because a previous cell was contentious, I’ll keep using that new cell” - this means that CAS collisions can theoretically be eliminated over time, with the expense of potentially creating a larger memory footprint for a single number.

Since the cells are all independently update-able and create-able, and based on multiple iterative passes, the process of calculating a value over them involves iterating each cell and getting a snapshot value from them independently. Because of that, it’s possible that during the iteration, some of the cells may be slightly out of date or non existent on my local thread.

Additionally, since this is all based on combining the values out of multiple cells together, it immediately implies that there are only certain accumulative operations where this segmentation can be used.

There are several new classes that extend Striped64 to provide relaxed-consistency classes for cases where you want to accumulate values in this way:

• LongAdder; DoubleAdder - Classes that allow threads to accumulate values into a long or double in a thread-safe, and extremely low-contention path. Example Usage: Accumulating total execution time for a particular call so you can calculate average execution time.
• LongMaxUpdater; DoubleMaxUpdater - Classes that allow threads to calculate the “max” value seen up to a point, again in a very low-contention implementation. Example Usage: Tracking the max execution time for a particular method call.
• LongAdderTable - A handy extrapolation of long adder into a hash table form. This is an optimized map of LongAdders (although it doesn’t implement the Map interface for a number of reasons) that is specifically designed to be as efficient as possible in the use of long adder values per key, and allows for decrementing, incrementing, and adding by key. It also will create the adders for you automatically simply as an operation of you incrementing. Example Usage: Tracking several call execution times for an application all in one data structure.

Let’s look at how these classes work internally to bring home the idea of cells for contention management. If we look at the LongAdder class as an example - let’s say we have a simple counter value we’re tracking for some method call, and it looks like this at one point:

LongAdder
|
*-- Cell[0] = 51352

Our thread comes in to increment the first cell and we keep getting a CAS collision. So, based on the collision heuristics, we decide to create a new cell and increment there:

LongAdder
|
*-- Cell[0] = 51494
|
*-- Cell[1] = 1

Note that Cell[0] has incremented several times outside of our control (other threads), and we also created Cell[1] to hold our new value.

To calculate the sum total for this long adder, we simply sum all of the cells together, returning 51495.

The internal documentation on the Striped64 draft class has phenomenal notes on the algorithm).

While discussing atomic numbers, it should also be noted that there are implementations of AtomicDouble and AtomicDoubleArray laid out in the extras package of this draft work as well. These would ideally bring true atomic floating point to Java for the first time, but as indicated on the draft group site, the extras folder is probably not going to make it into Java 8 directly. They do show how these can be implemented, however, which is a feat in and of itself.

What’s Next?

There’s a good bit more in the JEP-155 bundle, including stamped locks and some nifty fork join improvements. Those are for another time, however.

One of the recently announced JEPs is JEP 169 - Value Objects. Value objects are a number of tools for expicitly declaring that a Java object represents a raw set of vectorize-able values, rather than a composite set of memory values linked via pointers, and dynamically allocated on the heap.

As Java programmers, most of us are comfortable with (even if not entirely happy with) the distinction between primitives and objects. It’s one of those ugly, very un-academic pragmatics that you deal with because of the benefits it brings. Unfortunately, as the aforementioned JEP mentions, it’s also an ugly dividing line. You find yourself choosing between very low-level and hard-to-manage data structures and value types, or choosing more manageable high-level types, sacrificing the performance gains you would see otherwise:

In modern JVMs, object allocation is inexpensive, with a cost comparable to out-of-line procedure calling. But even this cost is often a painful overhead when compared to individual operations on primitive values. Thus, Java programmers face a binary choice between existing primitive types (which avoid allocation) and other types (which allow data abstraction and other benefits of classes). When they need to define small composite values such as complex numbers, pixels, or pairs of return values, neither approach serves. This dilemma often has no good solution, and the workarounds distort Java programs and APIs. Consider, for example, the lack of a good complex number type for those who program numeric algorithms in Java.

The general idea is allow programmers to give the JVM more knowledge about objects that are already designed to be immutable and simply represent a value, so that it can be treated in a more efficient way; much like primitives.

The example that is used repeatedly in the JEP is a class that represents a Complex number; call it java.lang.Complex. As you may or may not know, Java today doesn’t have a complex number value type. There are a number of open-source and academic examples of creating one, with the commonality between them being that they are written as a Java object. Usually, they are represented as a couple double values internally, and they have a numbef of methods for doing things like adding, subtracting, dividing, calculating cosine, and so forth. Apache-Commons Math has a perfect example.

However, if you think about it, there is really no reason this Complex value has a full heap allocated object. It’s really just a couple primitives that are bound together inextricably. But the only way to do this with pure primitives would be to juggle multiple primitive values manually, and that’s not exactly a pretty API: hard to explain to implementors, and very hard to add functionality around. Sadly, a lot of APIs that have to deal with quickly shuffling numeric values (such as rendering APIs) fall into the trap of having to deal with buckets o’ numbers.

This JEP is an attempt at tackling this problem. Once an object has been declared a value object, it can now be scalarized by the VM into a compact binary representation that can be propagated on the stack, and can even be interned in memory. In other words, the VM can treat the Complex class exactly like two double values held in a single memory vector; but the developer code can still handle it like an object, with all of the encapsulation and behavioral binding that implies.

Because the value object is being treated like a primitive, it now has no surrogate identity (no pointer location), and as such, it can’t be used for operations like synchronization and reference equality checks.

Boxing Benefits

One of the interesting notes about this proposal is the fact that it changes the cost and complexity of boxing and unboxing of values from primitive types and back. Consider this contrived example:

public void someMethod() {
	int val1 = 5;
	int val2 = 10;
	int result = sumofsquares(a, b));
	// ...
}

public Integer sumofsquares(Integer a, Integer b) {
	return square(a) + square(b);
}

public Integer square(Integer val) {
	int val = val.intValue();
	return val * val;
}

In this case, we have two primitive values in someMethod(), but immediately pass them into a method that expects boxed types. As such, the compiler is going to secretly inject code like this: sumofsquares(Integer.valueOf(val1), Integer.valueOf(val2)).

What this new value objects support would allow the compiler and runtime to do is defer any of boxing all the way until some complex behavior is invoked on the type - in this case that would be the intValue() invocation within the square method. However, since the compiler can determine it’s simply calling a method that returns the value component contained there-in, it can actually completely eliminate the boxing altogether.

The method tree then turns around and returns a boxed value again, but the compiler and runtime can again eliminate any boxing, as the method tree never deals with them in a complex way.

Therefore, somewhat surprisingly, the boxing to a reference style java.lang.Integer above can in fact be eliminated completely. The other exciting benefit is that your own value types can be treated this same way, even though (unlike int and Integer) there is no native primitive value directly representing your type. This opens a whole new opportunity for expressive and clean APIs that have to deal with primitives, closing many of the difficult “performance vs. readable” problems Java developers have faced.

Class vs Object

Several months ago I watched a presentation from Brian Goetz (can’t find the specific talk) where he discussed the potential for value objects in Java’s future, and at the time the thought was that it could be a new keyword or annotation on the type that indicated it was a value type. This proposal, however, discusses using a per-instance locking mechanism similar to:

Integer x = new Integer(123456);
// Not yet a value object...
x = x.lockPermanently();
// Now a value object...

There are some benefits to this manual locking:

• You can use some objects as reference types; if you’re synchronizing on Integer somewhere in your code (Why?) this would allow you to continue to do so.
• Initialization of objects that will eventually be value types can be done in multiple steps.
• Even if your code (or some library you use) doesn’t mark the object as a value type explicitly, the JIT can still analyze the usage of the object, and transliterate it to a value type internally as a form of runtime optimization.

This idea of value objects becomes a huge benefit when exploring expressive sophisticated functional programming models. Since one of the main tenants of functional programming is immutable types - if Java can in turn represent those immutable types as primitive values, it helps ensure that functional programming models don’t pay a penalty for their expressivity and immutability.

Today, Valve released the Steam for Linux beta client (more, and more) to 1000 lucky testers. It’s an exciting official event (I discussed this previously), and while the supported game list is still quite small, there is no surprise that nearly all of the humble indie bundle games that went to Linux are also available on Steam.

On another note, while there is a certain bit of “layman” reporting in this, I thought this was a surprising report from the Register on Nvidia releasing ‘double-speed’ drivers. Engadget has a more technical walkthrough as well.

It was only a couple of months ago that Linus gave Nvidia the finger, and there is good reason for that - so as an Nvidia card owner, I’m glad to see that Valve has encouraged to consume a large in-flow of patches and contributions to help them make their Linux offering less horrible.

In reality, the drivers they are releasing only fix performance for a few cards and likely for specific problems found from the Source engine, but even still, a little traction can go a long way. There have been a lot of announcements of potential Linux support recently between Valve, Unity3d for Linux (which is used aggressively in the indie space), Star Citizen by Chris Roberts (ala Wing Commander), and of course Humble Indie Bundle, things are starting to finally look up for Linux gamers!

In closing, here is Linus giving his sign language to Nvidia:

The folks over at Atlassian have been providing some form of hosted JIRA+code for some time - starting with a variety of variants of what they called “JIRA Studio”, up to their most current cumulonimbus offering: Atlassian OnDemand.

My company has been using these hosted forms of the Atlassian suite for upwards of three years now for a variety of things:

• Issue Tracking
• Code Repository
• Internal Documentation
• Client Support Tools
• Code Reviews and Auditing with FishEye
• CI Builds with Bamboo

At the time we signed up, the “Belle of the Ball” was FishEye with Subversion, and it has served us fairly well, overall. I will be the first to admit that it’s had its warts too, as most of you familiar with SVN are probably not surprised. It’s only been in about the past year or so that the Atlassian folks have supported any other legitimate options for VCS, and because of the sheer volume of code that we interact with at any point in time between our own products and clients we work with, we have stuck with SVN up to this point. Mountain moving takes time after all.

In a move that wasn’t entirely disappointing, but certainly felt aggressive, Atlassian recently announced that they are dropping support for hosted Subversion altogether - and they’re taking FishEye out along with it.

Looking back at the various blog entries, open tickets, and other breadcrumbs I found while frothing for better VCS support over the past couple years, I suppose I should’ve been able to read the tea leaves and see this one coming. They have been putting all of their feature effort into BitBucket after they bought it, and have made it clear that it was their direction for the future for some time now.

I suppose at some level I don’t blame them; FishEye is notorious for the amount of horsepower it requires (having been in a self-hosted environment with it previously, I can attest to this), and frankly, so is Subversion given the relatively poor delta management and the centralized nature of it - since one begets the other, I can imagine that it’s a rather ugly hosting proposition. Our experience over the past few years with hosted FishEye has been mediocre at best; the tool is very capable, but the performance in the on-demand space has been hit and miss.

Nonetheless, I found it rather surprising how quickly they have chosen to force the retirement. The cut-over is happening by October of 2013; I wouldn’t be surprised if that date moves some (often times their EOL dates do), but all the same, they are not doing any hand-waving about keeping SVN around.

At this point the move to BitBucket/DVCS will comfortably replace most of the features that FishEye has that we actually use, including code reviews and web-based browsing of the code; and of course, Git and Mercurial are both capable of replacing SVN whole-hog - it’s really just a matter of the system-administration and ramp-up for the team.

As a Linux-as-my-primary-desktop user (one of the paltry few) it’s exciting for me to see this coming. I currently dual boot to Windows 7 to do all of my PC gaming, but choose Linux for my dev environment because it’s tremendously more productive on any given day, for many of the same reason many devs prefer OS X (first-class terminal, high-quality integration with various VCS, etc).

I don’t know if this gamble by Valve will pay off in the long run, but I’m hopeful that it will. Things have really started to shift away from Windows-only in the past few years, and whatever the final form, I think that’s tremendously healthy.

Here’s Drew Bliss from Valve talking at UDS this year about their motivation, short-term plans, and overall goals for Steam on Linux:

(via Reddit)

• /feed is now /atom.xml
• /category/[...]/feed is now /category/[...]/atom.xml
• /tag/[...]/feed is now /tag/[...]/atom.xml

I’ve put in some 301s for those URLs, so hopefully feeds will automatically update for you.

If you have any issues with the site (links that don’t work, etc) please let me know!