Facebook Buys Acrylic

Vancouver-based Acrylic Software — maker of iOS and Mac apps — can now count itself among the few companies Facebook has decided to give the thumbs up of acquisition to. The Canadian software company is known for their iOS RSS reader app, Pulp.
Some believe this iOS expertise is what sparked Facebook’s interest in the company, rather than the app itself. As such, the social networking giant only bought the company, rather than buying rights to the apps. In the coming weeks, the Acrylic team will transition to San Francisco to become full-time Facebookers, leaving their iOS and Mac apps stagnant in their current form.
“Facebook is an invaluable service that we all use daily, and a company I believe is one of the most innovative and important around today,” writes Dustin MacDonald in the Acrylic blog.
“After visiting late last year, I discovered that we shared many of the same core product design goals and principles, and it soon became obvious that it was a natural fit. Simply put, there’s an opportunity at Facebook to have a big impact in many people’s lives. More importantly, Facebook is full of extremely talented people who will be able to help realize its full potential in the years to come.”
Though Pulp and Wallet (their password storage app) will remain available on their respective App Stores, the Acrylic team doesn’t have any plans to update these apps in the near future. MacDonald did not disclose any financial terms in his blog post.
Facebook has been making some strides in the past few months towards a more complete mobile experience. They famously dropped $1 billion to acquire the popular, all mobile photo sharing app Instagram.
Last month, the New York Times ran a story suggesting the Facebook iOS app could be getting a much needed speed boost.
As it stands, the Facebook app acts much like a web browser housed inside a thin, iOS wrapper. Their new updates to the app would put more of the heavy lifting in the hands of the iPhone’s hardware, rather than depending on the antennas and networks to pull down all the data from Facebook’s servers.
This past May, persistent rumors about a Facebook phone began to surface once more. According to an earlier New York Times piece, several Apple and Google employees had been contacted by Facebook recruiters, saying the social networking company has planned to build their own smartphone. Facebook has already hired several engineers who have history working with the iPad and iPhone.
One former Apple engineer in particular said he had a meeting with Mark Zuckerberg wherein the Facebook creator drilled him with questions about the inner workings of the iPhone. When asked about their plans to enter the smartphone wars against the likes of Apple, Google and Samsung, Facebook only repeated a statement from last year, saying, “We’re working across the entire mobile industry; with operators, hardware manufacturers, OS providers, and application developers.”

Continue reading →

Curing the hiccups

The H: Generally, what should you do about Java VM hiccups?
GT: First, you should watch for and be aware of any hiccups in your application behaviour, preferably at all times (including in production). Next, you should compare the hiccup behaviour to your expected and required responsiveness behaviour, e.g. a Service Level Expectation (SLE) or Service Level Agreement (SLA). With that information at hand, it is the job of Architect, Developer, and/or operations and deployment specialists to make the application behave as it should, which generally means removing hiccups that violate the expected behaviour by any means necessary (but not dwelling too much on ones that do not violate the expected behaviour).
So it is those hiccups – the ones that violate your application's expected behaviour – for which you need to figure out the cause and how to deal with it. It has been our experience that the nearly-universal dominant causes of application hiccups on most JVMs are Garbage Collection pauses, and that those dwarf other causes in both size and frequency. Eliminating GC pauses will usually leave system-related hiccups that range in the low tens of milliseconds, which can also be addressed if needed (e.g. for a low latency application) through tuning of system settings (e.g. power management modes, swap and filesystem behaviour, and avoiding deep scheduling queues).
In keeping the GC-related JVM hiccups to within expected levels, you are currently faced with two choices:

1. Continuously tune various GC controls and parameters in the hope of reducing the frequency of very large events (e.g. full GCs) to "acceptable" levels, and the frequency and magnitude of " merely large" events (e.g. "minor" GCs, young gen collections, etc.) to acceptable levels as well. These efforts will typically result in a compromise about the acceptable percentile of certain magnitudes of hiccups, because complete elimination of GC pauses of either kind is not practical on most JVMs.

2. Combine continuous tuning with coding in a "GC friendly" or "Heap friendly" way, in an attempt to reduce the pressure on a garbage collector's young or old generation, with the hope of reducing the occurrence or magnitude of "Bad GC" events. This practice (which has been successful to some degree in low latency applications) typically results in what I call "programming in Java syntax, but without the Java ecosystem", since, for it to be successful, the use of many core behaviours, as well as any third party code is typically prohibited.

or:

3. Address the core problem and eliminate GC altogether as a dominant cause of application hiccups. This is where Azul's flagship product – Zing – comes in. Zing's use of the C4 collector (which stands for "Continuously Concurrent Compacting Collector") simply and completely eliminates GC as a dominant cause for application hiccups, and does so without any special tuning or coding efforts or practices, and without the need for continuously re-tuning and/or re-coding.

Obviously, we believe Zing is a cure for the hiccups. It has been our experience that Zing will immediately bring enterprise applications to a worst case hiccup level in the low tens of milliseconds right out of the box. Those remaining hiccup levels, once Zing is deployed, are typically dominated by non-JVM system artifacts (e.g. scheduling pressure with many runnable threads competing for CPUs, or OS and hardware setting around power management and swap/file behaviour, all of which can be tuned and addressed if needed). In the low latency world, where scheduling pressure is already avoided as a matter of normal practice, we've seen applications immediately reach a worst case of below 10 milliseconds, and with relatively little tuning get to 1-2 millisecond worst case levels. Going below the 1 millisecond mark is quite possible, for those brave enough to tune their system (not their JVM) to provide that level of consistency, and to make their code provide it.

Continue reading →

Diagnosing hiccups

The H: A lot of developers might say "But I can see when GC kicks in so I don't need a measuring tool for it"; what would you say to them?
GT: First, jHiccup reports on any observed hiccups, regardless of cause. Hiccups can occur for a multitude of possible reasons, including GC, power savings artifacts, swapping, scheduling pressure, and other OS-level artifacts such as Transparent Huge Page compaction that is done in recent Linux kernels.
Second, jHiccup reports what an application actually experiences and observes, as opposed to what a log file for a JVM or an OS may "claim" has happened. Often reporting in JVM and OS logs is "honest", in which case the hiccups jHiccup will report should closely match up with pauses seen in GC logs. However, sometimes the times or events the JVM reports may be only part of the picture. For example, if you compare pause times reported by verbose GC logs with those reported by using additional flags like -XX:+PrintGCApplicationStoppedTime, you'll often see significant discrepancies. With jHiccup, you don't have to wonder if you have turned on the appropriate logging, and if the logging is accurate, optimistic, or pessimistic – you have a log of *observed* discontinuities in execution, and any discontinuity larger than 1msec simply cannot hide.
I recommend using jHiccup in addition to (and not in place of) other monitoring mechanisms. Results seen with other measurement tools should almost always be worse than those reported by jHiccup (since jHiccup reports the hiccups seen when trying to do absolutely no work). If jHiccup results conflict with those measured through other means (e.g. if an external response time measure shows much better percentile results than those observed by jHiccup), then either jHiccup or the other measurement mechanism probably has a bug or a "methodology problem".
The H: You've placed jHiccup in the public domain using the CC zero licence. Any particular reason for that uncommon licensing choice?
GT: It's the most permissive way I know of to allow people to use the code in any and all forms. Placing the code in the public domain removes any questions about conflict with other forms of licensing. I followed the example of what Doug Lea has done with much of his work, such as his extremely well adopted dlmalloc, as well as java.util.concurrent (all the sources originated by the JSR166 group were similarly placed in the public domain).
The H: Are there any enhancements you'd like to see?
GT: I'd love to see people do more with jHiccup, both in terms of using it as-is, and by incorporating its simple measurement technique as a common way of self-measurement by applications and application platforms.
I'd be happy to see people build non-Java versions (e.g. for the various .NET languages, as well as for Ruby, Python, etc. Maybe even for C/C++). I think the issue of implicitly assuming "platform continuity" for applications, and of ignoring or under-reporting and "platform discontinuity", is universal, and is especially prevalent in managed runtimes with automatic memory management (aka GC).
The H: How about integrating jHiccup with management platforms so people can spot hiccuppy JVMs?
GT: jHiccup was intentionally kept simple, and intentionally kept separate from any specific JVM, OS, or application platform. It would be trivial to take the data collected and reported by jHiccup and incorporate it for presentation as part of an overall monitoring or management solution. It's been placed in the public domain with exactly this sort of thing in mind.
The H: Does Zing detect its own hiccups if they happen or does C4 prevent that?
GT: In a way, jHiccup is there to keep everyone honest, and that includes Zing. No amount of logging or reporting by a runtime or an OS can be used as a replacement for logging the actual experiences that an application would see on such a platform.
Zing seems to do a fairly good job of reporting on what it thinks it is doing, and GC-related hiccups tend to be be a complete non-issue for Zing users. That's what C4 is meant for, after all. However, the best way for them to actually know that is to observe it with tools like jHiccup, rather than to believe what our JVM logs say.
With Zing, we most often find that observed hiccups are no longer dominated by GC effects, and as a result tend to be dramatically lower than those seen with other JVMs. However, hiccups in the multi-msec range can easily be seen, with causes ranging from scheduling pressure (having even a momentary situation with more runnable threads than available cores generally leads to ~10msec+ hiccups being observed), to power-management tuning artifacts, to background cron jobs being kicked off. In the very-low-latency space, we've seen people successfully tune "vanilla" Linux configurations running Zing such that the worst case observed hiccup levels (as reported by jHiccup) were kept well below 1msec.

Continue reading →

Java hiccups and how to beat them

Recently, The H was looking into Java Virtual Machine performance and in the process came across a different kind of performance evaluation tool, jHiccup, which promised to measure the hiccups that afflict applications in the real world. To find out more about this open source tool, The H talked to its author, Gil Tene, CTO of Azul Systems, makers of the high performance JVM Zing.

The H: Why do Java programs get the hiccups?
Gil Tene: Well, all programs get the hiccups. It's just that those running on modern-day managed runtimes (such as a JVM, or .NET, or Dalvik, or Ruby, etc.) have bigger causes for those hiccups than "what we were used to" up to the mid-90s.
We tend to think of computers as things that run continuously, without interruption, and we tend to treat interruptions in this model as "noise". I call any situation where (from the application's point of view) a computer is not running for a while a "hiccup". If the platform you run your application on exhibits "hiccups" with a magnitude that "matters" to your application, application response time behaviour will invariably be affected.
The reality is that computers often stop running programs for some short (for an arbitrary definition of "short") periods of time for all sorts of reasons: interrupts and their handling are microseconds-level disruptions. Context-switches can reach tens of microseconds, and scheduling delays (when more things are runnable than there are CPUs and the OS scheduler time-slices a CPU) are usually counted in "OS quantums" that range into the milliseconds (a 10msec quantum being pretty common occurrence). All this has been around for decades. Modern day environments add other interesting things, like power saving modes and hypervisor, that do more time slicing.
However, the biggest "gift" of all to modern-day hiccups usually comes from garbage collection. Most modern languages (most of those created since 1995, and many from before then) use some form of implicit, automatic memory management, with the managed runtime environment they run on performing implicit garbage collection. Java is such an environment – arguably the most successful one in history – and most people who run on or use a Java JVM know what garbage collection is: it's that thing that makes their application pause every once in a while.
In most modern day JVMs (e.g. Oracle HotSpot and jRockit, OpenJDK, IBM J9) garbage collection invariably involves "stop-the-world" events. These stop-the-world events range from frequent "young generation" or "minor" collections that usually come in 10s or 100s of millisecond "hiccup" chunks, to the bigger "major" collection (aka "oldgen", "Full GC") that can take several seconds to complete. The length of the bigger GC "hiccups" usually depends on the amount of live data in the program at the time of collection. The larger the live data set (and the larger the heap, for some/most JVMs), the larger the pause you can expect to see.
When a garbage collector "stop the world" for any reason, applications will experience a "hiccup" in execution. Whenever this "hiccup" reaches a magnitude that matters to the application, this effect will typically dominate the worst-case and high-percentile (e.g. 99.9%) response time behaviour of the application. For example, if an application typically responds in sub-second times to user requests, having regularly occurring 3 second "major" GC pauses would dominate the application's response time behaviour. If an application is expected to respond in milliseconds (as is common in Telco and financial applications), even the frequent "minor" GC events tend to dominate the application's response time characteristics.
The H: Is how those hiccups manifest dependent on the VM?
GT: Yes. More precisely, it depends on the garbage collector used, and the garbage collector is a key part of a JVM.
A lot of work has been done on garbage collectors on current JVMs, but most of that work hasn't focused on eliminating hiccups or reducing their absolute magnitude. Instead it has been focused on making them more "rare" through a combination of intricate tuning efforts and garbage collector tricks. The commonly used JVMs on the market today all exhibit significant stop-the-world pauses on a regular basis – something that is readily observable by looking at "hiccup charts" that can be collected (with jHiccup) for pretty much any Java application. Most Java applications with more than a GB or two of heap will exhibit multi-second hiccups multiple times per day or week, and hiccups in the tens or hundreds of milliseconds several times per minute. When heap sizes grow and allocation rates increase to consume more than a tiny fraction of a modern-day commodity server, these numbers tend to get much worse.
As an example of how the choice of VM can dramatically effect the hiccup levels that an application experiences, you can look at the behaviour of Azul's Zing JVM. Zing is specifically focused on dramatically reducing both the absolute magnitude and frequency of application hiccups experienced due to garbage collection. Zing's C4 garbage collector uses a concurrent algorithm for both minor and major collections, allowing it to perform garbage collection without incurring those long stop-the-world events that are inevitable on other JVMs.

Continue reading →

Jigsaw Shelved Until Java 9

Oracle is dropping Jigsaw from Java 8 in order to meet the scheduled release date of September 2013.

Jigsaw is a project designed to provide a standard module system for the Java SE Platform, and to apply that system to the Platform itself and to the JDK. It was originally planned to be part of Java 7 but was postponed shortly after Oracle  took control of Java along with two others, Project Lambda and parts of  Project Coin.

Until now the expectation was that it would be included in Java 8, the release date of which  had already slipped from late 2012 to September 2013. However, Mark Reinhold, chief architect of the Java Platform Group, has now posted on his blog that he plans to postpone Jigsaw till Java 9.

Reinhold’s reasoning is that:

"the proposed development schedule for Java 8 expects work on major features to be finished by May 2013, in preparation for a final release around September. Steady progress is being made, but some significant technical challenges remain. There is, more importantly, not enough time left for the broad evaluation, review, and feedback which such a profound change to the Platform demands.”

The JDK is being released every two years to provide stability and give developers a clear idea about what the future holds. Putting Jigsaw off until Java 9 won’t be a problem for most developers, but modularity is a feature that developers of large systems have been asking for.

The reaction to Reinhold’s blog post has been less than enthusiastic. Reinhold titled his blog post “Late for the train”, and commented that

“if a major feature misses its intended release train then that’s unfortunate but it’s not the end of the world: It will be on the next train, which will also leave at a predictable time.”

However, as one comment says, what's the point if the train arrives "on time" without any cargo?

Another commenter says he finds it a bit ridiculous that Jigsaw is stripped from JDK 8 as it was already stripped from JDK 7, asking “What will be next? Moving it to 10 after 9, 11 after 10? Just give up the idea and use Maven. It's here already and serves well.”

Other comments questioned the two-year release cycle, suggesting that a JDK 8.5 after a year would be a suitable compromise. One commenter asks:

“How much time over the JDK8 ship date are we talking about?  If it took another 6-8 months over the current 8 months, would that be enough time to stabilize Jigsaw?  I'd be willing to wait for that if it was 6-8 months.”

So  it looks as if the only big new feature in Java 8 is going to be Lambda, which is currently still in the release train. The other "major" features promised are a new Date/Time API and the parts of project Coin that didn't make it into JDK 7, unsigned literals and collection support.

Continue reading →

AICPA Announces Five Tips to Disaster-Proof a Small Business

Hurricane season is upon us, offering a reminder that small business owners need a disaster plan, even if it’s the most basic kind. It’s never easy to carve out time to think about the unthinkable, but having a business continuity blueprint in place can mean the difference between a firm’s survival or failure in the wake of a significant fire, flood or other calamity.
To get the ball rolling, we talked to the experts – including three firms that have been to the brink and back during Hurricane Katrina, the devastating 2011 tornado in Joplin, Mo., and Hurricane Irene. Here’s their advice:

1. Go digital, and get in the cloud. Paper records do not fare well in water, wind or fire. Having a paperless or near-paperless office makes it easier to store and replicate information – and when disaster strikes, having records stored in multiple secure locations is crucial. Firms can be diligent about backing up computer files, but it can be useless if recovery disks are stored in the same location as servers. With cloud-based solutions, firms can get back on their feet quickly using laptops, mobile devices and home computers, according to Erik Asgeirsson, president and CEO of CPA2Biz, the technology subsidiary of the American Institute of CPAs. Make sure your cloud partners are using best practices to protect your data, though, because not every vendor is the same – and a disaster’s aftermath is a terrible time to figure that out, he said.
2. Laptops are easier to lug than a desktop computer. It’s tough trying to cart a monitor, computer tower, keyboard and mouse out the door when you need to clear out fast. Laptops are portable without a significant trade-off in computing power. “We used to be a 50 percent desktop, 50 percent laptop office,” said Les Nettleton, Director of Information Technology at Bourgeois Bennett, LLC, which weathered Hurricane Katrina. ‘We changed that now – we’re a full laptop shop.”
3. Have a virtual meet-up spot for your employees. Just as families pick a spot outside their home to make sure everyone is safe and accounted for in an emergency, companies need to have an online gathering spot to share information and begin rebuilding operations. Remember, cell service, company email and other means of communication may be down for the count. “What we’ve done now is have an externally hosted bulletin board with personal email addresses and cell phone numbers,” Nettleton said.
4. Automated, online backups are the way to go. A year before a deadly tornado leveled CPA Nick Myer’s Joplin, Mo., office, a staffer lost his laptop – and key information stored on the hard drive wasn’t available elsewhere. “That showed the weakness in our backups, because they weren’t happening,” he said. The firm signed up for an online backup solution – and data loss was one thing Myers didn’t have to worry about when the twister shattered the business’ servers, PCs and other files.
5. Your business is only as sturdy as the people who make it run. In the wake of a disaster, some employees may have lost everything – and the last thing they’re worrying about is work. “The No. 1 thing we needed to do was getting paychecks into people’s hands,” Nettleton said of the post-Katrina chaos. Helping create stability with financial affairs can go a long way in easing workers’ minds, and the AICPA can help with the primer

Continue reading →

Athena Smartcard's IDProtect V6 Java Card(TM)

Athena Smartcard announced today that its IDProtect V6 Java Card™ cryptographic smart card achieved a trio of worldwide security certifications by receiving the International Common Criteria certification EAL +4, the US Government FIPS 140-2 Level 3 and ICP-Brazil approvals. Accreditation by three of the most respected global security standards bodies verifies that the Athena smart card platform has completed a rigorous independent testing process; which included evaluation of its research and development processes and facilities on multiple sites, implementation, testing and production, and that it conforms to standards sanctioned by the leading US, European and Brazilian security standards organizations.

Products based on the Athena IDProtect V6 Java Card™ include Digital Signature (SSCD) applications based on the IAS-ECC specifications issued by GIXEL and conforming to the European Citizen Card standard, PKI applications based on the Athena LASER and IDProtect Client middleware and Digital Signature and Authentication conforming to the Brazilian government requirements.

Millions of units of Athena's IDProtect Java Card are already deployed in Government and Enterprise projects worldwide and it is being utilized as a Secure Element in several embedded devices which require a high level of security, as evaluated by the various security organizations.

Masaru Kosaka, Chairman and President at Athena, commented: "Being awarded the 3 leading global security certifications, Common Criteria EAL +4, FIPS 140-2 Level and ICP Brazil, on a single smart card platform, is testament to the continuous hard work and commitment that Athena puts into the security aspects related to the design and development of its products and to meeting its customers' security needs, wherever they are based. Having the product certified, by 3 different certification bodies, and evaluated at 3 independent certification laboratories provides our customers with the high level of confidence and trust that is needed in order to deploy modern large scale smart card applications."

About Athena Smartcard

Athena's innovative and secure smart card operating systems, on-card applications, middleware and reader technologies enable our partners to offer 'state of the art' National ID, Digital Signature, eGov, ePassports, Transportation, Secure Elements and advanced contact and contactless payment solutions by removing the development, support and certification barriers associated with in-house R&D.

Using close relationships with industry leading silicon vendors, card and inlay manufacturers, and a permanent staff of industry leading engineers Athena offers highly secure, flexible, and cost effective solutions.

With offices in Asia, Europe and the Americas, and through a network of industry leading firms, including card manufacturers in the world's fastest growing markets such as Brazil, Asia, Russia, and Africa, Athena is ideally positioned to provide timely and professional hand's on support, help facilitate the transition to secure chip technologies, and allow our growing list of partners to stay competitive.

Continue reading →